@Alwin Here you go. Fresh, vanilla, unconfigured Arma3 DS installed via SteamCMD as of Thu Jan 12 14:13:34 CET 2017. Crash was triggered via sending SIGINT. arma3server binary sha1sum is 20d928b05ecd5e1613efbd6c1d7f1e1c56a3de5d.

@Alwin Your efforts are much appreciated :)

@Alwin While you're at it, you may also want to take a look at T80679. It describes how it should be possible to trigger a graceful shutdown not only with SIGINT, but with SIGTERM as well. I reported it 2 years ago ;)

Thanks for reporting this ;) Unfortunately, nobody bothered to investigate (or even fix) this issue following my initial report.

Taking a quick look at the involved registers in both this and T122774, I'd take an educated guess that the underlying issue is the same and can be triggered by either SIGINT or #shutdown. It just moved around a little in the meantime (new binary version). With the arma3server binary version 1.66.139586 (sha1sum 20d928b05ecd5e1613efbd6c1d7f1e1c56a3de5d) both my servers crash at exactly the same instruction address as in T122774.

Almost 2 years later, this issue still persists with the current Linux Dedicated Server version (1.66.139494). Since I manage my servers using systemd, this issue can be mitigated using the KillSignal=SIGINT directive inside the [Service] section, instructing systemd to terminate the process with SIGINT, instead of the default SIGTERM.

According to the forums, a "proper fix is on the way": http://forums.bistudio.com/showthread.php?169926-Linux-Dedicated-Server-feedback&p=2863385&viewfull=1#post2863385

Yep, this has been fixed for 2+ months now. Just another example for how little attention the bugtracker receives from BI staff ...

You're welcome guys.

@jayjay: You can easily ignore "SteamAPI_IsSteamRunning() failed". I've been getting it for quite some time. It means there's no instance of the Steam Client running, which is only logical, because it's a server, not a desktop machine running the Linux version of the Steam Client.

You do not need to install the insane dependencies of the broken steamclient.so. Simple replace it with the steamclient.so from your SteamCMD installation.

I just filed a more accurate bug report, which describes above fix: #0022391

Firstly, according the the Biki values higher than 2047 will fall back to 2047, which is not what happens: https://community.bistudio.com/wiki/Arma_3_Startup_Parameters#Performance

Secondly, 64-bit Linux kernels have always granted 32-bit user-space applications the entire 32-bit address-space (unlike Windows which requires a 32-bit executable to be linked with /LARGEADDRESSAWARE to unlock the full 4 GiB). Consequently I consider 0 to 4096 a logical and thus valid range for -maxMem=.

Thirdly, this is an integer overflow due to an unchecked input parameter, which is always(!) a software bug. If a user can supply parameters which can lead to unexpected behaviour this must be caught by the application in question.

Fourthly, the -maxMem= values do not behave as advertised. Apparently the server uses way more memory than permitted via -maxMem= (after the integer overflow), but at some point fails anyway.

This bug is related to bug #22323.

Or to rely on 'configName (configFile >> "CfgMagazines" >> _x)' instead of 'toLower _x' as I do, since I want to preserve the case for pretty printing purposes.
IMHO simply everything should have been case-sensitive from the start (including the '>>' operator), which would prevent issues like this one. Just one of the many rough edeges of SQF.

This issue got worse in the meantime. Aircraft guns now cannot even scratch well armored APCs like Panther and Mora (MBTs are inpenetrable as well).
I opened a new issue: http://feedback.arma3.com/view.php?id=22146