Swift for Linux debug vs. release configuration, any recommendations?

Server Development
1

Hello everybody,

I have a fairly large C based code based backed that I successfully wrapped into nice small swift packages around swift 2 timeframe, and has been using dockerized in production ever since. Even before the swift docker images were official. Huge memory savings and performance gains, clean workflow, so I never want to go back. Thanks everybody working on swift and swift pm.

I remember in the past that I had to build using swift build --configuration debug otherwise the executable would be crashing randomly with cryptic stack traces. Apparently due to bugs in optimization. This has improved and at some point in time and I remember finally switching to swift build --configuration release around swift 4.

In production, surviving many docker rebuilds and point release updates of swift compiler and various dependent components everything was shiny and happy until this week when I tried to swift build --configuration release using swift 5.1.1.

The app started behaving strangely - not crashing - but is apparently hitting either memory corruption, or some kind of low level logic bugs.

Problems fixed by using swift build --configuration debug as in the past, or by moving back to swift 5.4.3 which works super stable in production in release mode. Like 100 days of uptime under serious load with no troubles.

I could not yet track down precisely what is happening, to figure out whether this is a mistake on my side or a bug in linux swift, but I am looking for a general advice from like minded people running swift on the server.

  1. Should I stick to swift build --configuration debug to make sure my code on Linux is functionally correct and stable? Does anybody use --configuration release reliably?

  2. Is there a place to automatically follow/track bugs and issues reported against swift/linux so that I am aware of the current state?

I am comfortable living on the bleeding edge, I am just trying to figure out some best practices.

thanks,
Martin

2

For one - definitely run in release configuration. You should see huge performance improvements compared to debug. I use it for tens of server-side Swift client problems with no issue.

For 2 - bugs are on bugs.swift.org but finding out what is a Linux issue and what is fixed it what release (including the Linux only patch releases) is definitely something that can be improved

5 Likes
3

Thanks for your answer Tim, for anybody following this thread:

My issue was actually caused by one of the C libraries that I am wrapping and its use of inline assembler that was wrongly compiled/optimized with clang >= 12 in -O2 mode.

The solution was to fix the inline assembler to compile properly against latest clang, and therefore latest swift.

Which brings me to another question that I may try to hijack here:

1/ Is it possible to test swift packages built in release mode? My attempts with swift test --configuration release --Xswiftc --enable-testing just hang and do nothing.

2/ Is it possible to automatically invoke say make test as part of swift build or swift test? I have not found anything and am not sure where does the extensible build tools proposal stand currently, but invoking make test somewhere would definitely help prevent these issues in the future.

anything I am missing?
Martin

4

The "command plugins" are still underway through swift evolution, though they're there in nightly builds of toolchains if you wanted to play around a bit. Though nightly builds are not recommended for production builds of course. To track the plugin proposal's progress (and info how to use them in the nightly toolchain), see here: SE-0332: Package Manager Command Plugins - #10 by abertelrud

1 Like