[Runtime Issue]: Dedicated server crashes on ARM64 when built on Ubuntu 20.04 and running though systemd

[notimaginative]

Build Version

a4ef5fd0d56d56a47fc0b92f28b22788235f8441

Operating System Environment

• [ ] Microsoft Windows (32-bit)
• [ ] Microsoft Windows (64-bit)
• [ ] Mac OS X
• [X] Linux (specify distribution and version below)

CPU Environment

• [ ] x86 (32-bit Intel/AMD)
• [ ] x86_64 (64-bit Intel/AMD)
• [ ] ARM (32-bit)
• [X] ARM64 (64-bit; sometimes called AArch64)
• [ ] Other (RISC V, PPC...)

Game Modes Affected

• [ ] Single player
• [ ] Anarchy
• [ ] Hyper-Anarchy
• [ ] Robo-Anarchy
• [ ] Team Anarchy
• [ ] Capture the Flag
• [ ] Bounty
• [ ] Entropy
• [ ] Hoard
• [ ] Monsterball
• [ ] Cooperative

Game Environment

No response

Description

Attempting to run a dedicated server with systemd will crash during load with a buffer overflow message. If the build is simply run on the command line with the same options then it works fine. This appears to happen regardless of mission or game type, and only appears to happen with Release builds (Debug builds work fine).

It appears to only affect ARM64 builds created on Ubuntu 20.04. Builds created in Debian 12 work as expected with no crashes. Testing a Release build created on Ubuntu 20.04 with Debian 12 still crashes if run through systemd. A Debug build works.

This does NOT appear to affect x86_64 builds with the same tests.

It was tested with v1.5.0, the listed commit hash, as well as #568, all with the same results.

Compiler version used on Ubuntu 20.04 (g++): Ubuntu 9.4.0-1ubuntu1~20.04.2 Compiler version used on Debian 12 (g++): Debian 12.2.0-14

The cmake version on the Ubuntu 20.04 host was updated to the newest available from cmake.org. All other software was the current default versions available from the respective distros. Build steps followed were as listed in BUILD.md.

d3.log

Regression Status

No response

Steps to Reproduce

Compile a Release build for ARM64 on Ubuntu 20.04. Create a dedicated server configuration and attempt the run the build through systemd.

An example systemd unit file (adjust paths as appropriate):

[Unit]
Description=Dedicated server for Descent 3
After=network.target
ConditionFileIsExecutable=%h/games/descent3/Descent3

[Service]
Environment="SDL_VIDEODRIVER=dummy"
WorkingDirectory=%h/games/descent3
ExecStart=%h/games/descent3/Descent3 -dedicated %h/games/descent3/dedicated.cfg -useport 2092
ExecReload=/bin/kill -HUP $MAINPID
StandardOutput=file:%h/games/descent3/descent3.log
StandardError=inherit
KillMode=process
RestartSec=30
TimeoutStopSec=20
Restart=always
Type=simple
NoNewPrivileges=true

[Install]
WantedBy=default.target

Save file to ~/.config/systemd/user/descent3-server.service, run systemctl --user daemon-reload followed by systemctl --user start descent3-server.service. Check output of ~/games/descent3/descent3.log

[JeodC]

Extra.gam loading occurs starting in manage.cpp:L1326 if it helps any debugging

[jengelh]

What's the content of dedicated.cfg?

[winterheart]

OK, I've reproduced error on my environment, and this is not related to ARM64. Supplying very long argument (more than 35 chars) to -dedicated will cause SIGABRT on LoadServerConfigFile() strcpy that not checking length on input. @notimaginative could you please test #578 fix?

[notimaginative]

Won't have a chance to test that PR until later, but I have confirmed that if the argument to -dedicated is less than 35 chars then it works. Still not sure why I was unable to reproduce this issue with Debian 12 or on x86_64 builds using the exact same command line and long argument length though.

I'll update again once I've tested 578.

[jengelh]

The buffer-overflow caused by strcpy(server_config_name, ...) leaks into the next field, connection_name. It is conceivable that, when ConnectionName= is set in the config file, that it's overwritten again and a problem may not manifest in that particular instance.

I justifiable was eager to see the file contents (too).