Bug#1111671: openarena-server: Dedicated server segfaults during startup on mips64el, riscv64, s390x

[Simon McVittie]

Package: ioquake3-server,openarena-server
Severity: normal
Tags: upstream
X-Debbugs-Cc: debian-mips at lists.debian.org, debian-riscv at lists.debian.org, debian-s390 at lists.debian.org
User: debian-mips at lists.debian.org
Usertags: mips64el
User: debian-riscv at lists.debian.org
Usertags: riscv64
User: debian-s390 at lists.debian.org
Usertags: s390x
Control: found -1 ioquake3-server/1.36+u20250316.526edd3+dfsg-1
Control: found -1 openarena-server/0.8.8+dfsg-8

ioquake3/server/openarena-server have been compiled on all architectures 
for many years, but on several architectures they don't actually work 
(and perhaps never have). (The same is probably true for the GUI game 
engine, but that isn't feasible to test on a porterbox, and would have 
to be run on a non-headless system, either fully-emulated or on real 
hardware.)

I was prompted to check this by changes in ioquake3's build system that 
make it fail to build on architectures that aren't in their list of 
known architectures (again). I have a simple change in mind to fix that, 
but I expect it would be rejected upstream unless I can name an 
architecture where I tested it and it works. But, on every release 
architecture that is not already in their list (plus mips64el which is 
no longer a release architecture but still has a porterbox), it turns 
out that openarena-server already segfaults during startup:

$ export DEBUGINFOD_URLS=https://debuginfod.debian.net
$ OPENARENA_DEBUGGER="gdb --args" /usr/games/openarena-server +map oa_dm1
...
Starting program: /usr/lib/ioquake3/ioq3ded +set com_basegame baseoa +set fs_basepath /usr/lib/openarena-server +set com_homepath .openarena +set com_legacyprotocol 71 +set com_protocol 71 +set sv_master1 dpmaster.deathmask.net +set cl_motd 0 +map oa_dm1
...
ioq3 1.36+u20250316.526edd3+dfsg-1/Debian linux-mips64el Mar 17 2025
----- FS_Startup -----
...
Loading DLL file: /usr/lib/openarena-server/baseoa/qagamemips64el.so
...
^3!readconfig: ^7could not open admin config file admin.dat
Sprees/Kills: loaded 1 killing sprees, 0 death sprees, and 0 multikills.
]
Program received signal SIGSEGV, Segmentation fault.
0x000000fff7d42890 in __GI_strcmp () at ../sysdeps/mips/strcmp.S:103
(gdb) bt
#0  0x000000fff7d42890 in __GI_strcmp () at ../sysdeps/mips/strcmp.S:103
#1  0x000000aaaaacd024 in SV_SetConfigstring (index=20, val=<optimized out>) at code/server/sv_init.c:119
#2  0x000000aaaaacc204 in SV_GameSystemCalls (args=<optimized out>) at code/server/sv_game.c:379
#3  0x000000aaaab14db8 in VM_DllSyscall (arg=<optimized out>) at code/qcommon/vm.c:352
#4  0x000000ffee1e09fc in SP_worldspawn () at code/game/g_spawn.c:616
#5  0x000000ffee1e0ca8 in G_SpawnEntitiesFromString () at code/game/g_spawn.c:681
#6  0x000000ffee16d680 in G_InitGame (levelTime=<optimized out>, randomSeed=<optimized out>, restart=-299863640)
    at code/game/g_main.c:789
#7  0x000000ffee17339c in vmMain (command=<optimized out>, arg0=<optimized out>, arg1=<optimized out>,
    arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>, arg5=<optimized out>, arg6=<optimized out>,
    arg7=-1430284960, arg8=-1430640672, arg9=-1431512468, arg10=0, arg11=0) at code/game/g_main.c:424
#8  0x000000aaaab164a8 in VM_Call (vm=0x14, callnum=-1430612448) at code/qcommon/vm.c:891
#9  0x000000aaaaaccc1c in SV_InitGameVM (restart=qfalse) at code/server/sv_game.c:891
#10 SV_InitGameProgs () at code/server/sv_game.c:945
#11 0x000000aaaaacda6c in SV_SpawnServer (server=<optimized out>, killBots=qfalse) at code/server/sv_init.c:492
#12 0x000000aaaaac63ec in SV_Map_f () at code/server/sv_ccmds.c:211
#13 0x000000aaaaae6134 in Cbuf_Execute () at code/qcommon/cmd.c:248
#14 0x000000aaaaaebc0c in Com_Frame () at code/qcommon/common.c:3164
#15 0x000000aaaaabfa30 in main (argc=-1430814720, argv=0xffffff32b8) at code/sys/sys_main.c:875

I think this might be a problem with how "syscalls" from the game plugin 
(upstream it would be interpreted bytecode, but in Debian we use a 
native loadable module for DFSG reasons) call into functions in the 
engine: the game plugin calls a varargs function with arguments that are 
a mixture of pointers and ints, but the engine reads them all off the 
stack as intptr_t. This works on at least amd64, arm64 and ppc64el 
(presumably each argument is widened to be register-sized on those 
architectures), but crashes on riscv64, s390x and mips64el (presumably 
on these architectures, writing an int only stores 4 bytes on the stack 
but reading back an intptr_t consumes 8 bytes).

Unfortunately, the calling conventions between the engine and the game 
plugin are ABI, so we are not able to change them to something more 
reasonable and less varargs-based, like an array of pointer-sized 
objects.

Apparently nobody has noticed this crash until now, which suggests that 
ioquake3 has no users on the affected architectures. This means that 
inability to compile the new version on those architectures would not 
actually be a functional regression.

Upstream, ioquake3 has a dual role: it's an engine for the proprietary 
Quake 3 Arena game, and it's also an engine that can be used as a basis 
for Free games like openarena. When used for Quake 3 Arena (proprietary 
data required, there is a gratis demo that can be packaged with 
game-data-packager), both the engine and the game plugins come from the 
ioquake3 project. When used for openarena as packaged in Debian, the 
engine comes from ioquake3 but the game plugins come from openarena, 
which is a fork of the same codebase as ioquake3. I'm unsure at this 
stage whether the bug is on the engine side or the game-plugin side, so 
for now I've reported the bug against both packages.

    smcv