Package: ioquake3-server,openarena-server Severity: normal Tags: upstream X-Debbugs-Cc: [email protected], [email protected], [email protected] User: [email protected] Usertags: mips64el User: [email protected] Usertags: riscv64 User: [email protected] 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
