Your message dated Sat, 23 Aug 2025 15:50:24 +0000
with message-id <[email protected]>
and subject line Bug#1111671: fixed in ioquake3 1.36+u20250822.9d2227c+dfsg-2
has caused the Debian Bug report #1111671,
regarding openarena-server: Dedicated server segfaults during startup on
mips64el, riscv64, s390x
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1111671: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1111671
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
Source: ioquake3
Source-Version: 1.36+u20250822.9d2227c+dfsg-2
Done: Simon McVittie <[email protected]>
We believe that the bug you reported is fixed in the latest version of
ioquake3, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Simon McVittie <[email protected]> (supplier of updated ioquake3 package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Sat, 23 Aug 2025 11:40:38 +0100
Source: ioquake3
Architecture: source
Version: 1.36+u20250822.9d2227c+dfsg-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Games Team <[email protected]>
Changed-By: Simon McVittie <[email protected]>
Closes: 1111671
Changes:
ioquake3 (1.36+u20250822.9d2227c+dfsg-2) unstable; urgency=medium
.
* d/p/Remove-unused-matha.S.patch,
d/p/asm-Remove-unused-S_PaintChannelFrom8.patch,
d/p/client-Remove-i386-GNU-assembler-version-of-S_WriteLinear.patch:
Add proposed patches to fix FTBFS on armel and armhf
* d/rules: Pass CPPFLAGS to the assembler (thanks, blhc)
This probably doesn't matter in practice, since the assembler code
doesn't manipulate strings and isn't affected by _FORTIFY_SOURCE.
.
ioquake3 (1.36+u20250822.9d2227c+dfsg-1) experimental; urgency=medium
.
* New upstream snapshot
- Build everything with -fvisibility=hidden, avoiding symbols from the
executable interposing symbols of the same name in game modules
(Closes: #1111671)
* d/p/cmake-Only-link-snd_mixa-into-the-client-not-the-dedicate.patch:
Add proposed patch to fix one reason for FTBFS on i386
* d/p/cmake-Set-up-USE_ARCHLESS_FILENAMES-at-top-level.patch,
d/p/qcommon-Build-generically-for-otherwise-unknown-architect.patch:
Add proposed patches to fix the build on architectures not
specifically recognised by upstream
* d/rules: Build with SSE2 on i386, fixing another reason for FTBFS.
The new upstream snapshot doesn't build successfully on i386
without it. As per the trixie release notes, SSE2 is required now,
so it doesn't seem productive to go to extra effort to avoid that.
.
ioquake3 (1.36+u20250820.03c5ee0+dfsg-1) experimental; urgency=medium
.
* New upstream snapshot
* d/copyright: Update Files-Excluded
* d/copyright: Update location of some files that were moved
* Use the new upstream CMake build system
* Game modules are now loaded from cgame.so, qagame.so and ui.so,
without architecture-specific suffixes.
This simplifies the packaging considerably, since we no longer need
to track the corresponence between Debian architectures and their
ioquake3 names.
Add Breaks on older versions of openarena{,-server}, which relied
on the architecture suffixes.
* dlopening libcurl is now the only option, so do that.
Generate ${dlopen:Depends}, ${dlopen:Recommends} for dlopen'd
dependencies.
* Build-depend on OpenSSL libcurl, not GNUTLS libcurl. This is the
SONAME that ioquake3 will dlopen.
* d/p/debian/Compile-successfully-against-libcurl-7.52.x.patch:
Drop patch, no longer relevant in any supported Debian release
* d/p/build-Link-game-cgame-ui-modules-to-LIBS.patch:
Drop patch, fixed differently in the CMake build system
* A known regression in this version is that it will not compile
successfully on architectures not explicitly listed by
upstream. It isn't clear whether any of the affected architectures
worked: at least mips64el, riscv64 and s390x already did not (#1111671)
Checksums-Sha1:
6de4715026979a2bd0fdc92cf2233e9b630cf4cb 2613
ioquake3_1.36+u20250822.9d2227c+dfsg-2.dsc
62bf41f5bc9a6915234c292ba77657f85d882c48 32016
ioquake3_1.36+u20250822.9d2227c+dfsg-2.debian.tar.xz
241da902150cc91cb12a5bee727e417f5ec9c5d0 3909280
ioquake3_1.36+u20250822.9d2227c+dfsg-2.git.tar.xz
9ea08de1499773353ee7c200b47c653bce7eadbf 18146
ioquake3_1.36+u20250822.9d2227c+dfsg-2_source.buildinfo
Checksums-Sha256:
277de79f4069780d5135076ea4485019dba57fc78a8a47610e60577ed73c39da 2613
ioquake3_1.36+u20250822.9d2227c+dfsg-2.dsc
14475f5eec8addd407c354b4b37d8fbc5204a3ca97a96b410caaca24232acf6e 32016
ioquake3_1.36+u20250822.9d2227c+dfsg-2.debian.tar.xz
82fb34dd0929078b0cd2005815e3ca0a9c8b3eed6cade352cae599cb33186edb 3909280
ioquake3_1.36+u20250822.9d2227c+dfsg-2.git.tar.xz
c1f98da21f08b066ef0e70c0e1e6f67e4e1d05ec37f67dbb695f5fe13d0d9718 18146
ioquake3_1.36+u20250822.9d2227c+dfsg-2_source.buildinfo
Files:
ff38326209e6b1317eba383061e47f61 2613 games optional
ioquake3_1.36+u20250822.9d2227c+dfsg-2.dsc
85075e3613b3653094bc1e66ce0ff16e 32016 games optional
ioquake3_1.36+u20250822.9d2227c+dfsg-2.debian.tar.xz
4576de35a1d3f80e37fd7d39ded4d6f5 3909280 games optional
ioquake3_1.36+u20250822.9d2227c+dfsg-2.git.tar.xz
ad6426e93b84bf97a1c3c7a6218c24a3 18146 games optional
ioquake3_1.36+u20250822.9d2227c+dfsg-2_source.buildinfo
Git-Tag-Info: tag=fb39727424f7ff42503782579f826e3ce8b3cb22
fp=7a073ad1ae694fa25bff62e5235c099d3eb33076
Git-Tag-Tagger: Simon McVittie <[email protected]>
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEN02M5NuW6cvUwJcqYG0ITkaDwHkFAmip3VsACgkQYG0ITkaD
wHkwdA/+PIshDtnhjmYDUM0bb5ca67HeLVC4AZlAfo6aZuUhFSP6DI5yJUt725/8
D1vRnoMhDDK3o3hUIScBiaPijBrU6i4lJZakxDKVhIed8yElLq64cq/gWgE+1oOS
wfniD0Aw/30fq0zt0uSUjKPGSHuFshpN5oiB2yvvcEZvQKL57U40QFNsFx0+lVXP
l+hQO2edIT6flUq1ou078554uApHmrb8Md75rLjBc5fxHe0xmwC52nWsHYjGhEzz
myuvVeZ9u6fJHBP2+gUuevezqmX08QdebS6ZZquUMTqvJ3KkJr+v7o7iZozi3YtG
VCAcsFHS3YzgMu/hgB3jVVUNoRUru2kvZbZv8j+34FnrO/PekcRDw5/LteBTo+h2
/IK1fEE5PoxB9yhyn00V9RcULG91zdO036M916XgLjPV8CBRIFV7Y3nPI9WHWh+t
l4io34mIqmuQRltxuKrlaSvn5cArbTrNrnoEd1DQ0OrMdRphigT7akkRKxwUcLh2
W7ILME5aghsuzkLgYkOHdVSWWKdg1sQ6GYy/16n2V1ugb9aU8DJfHcjE2otQ8HRG
LOb+loru+WvireD4ANKKyGkpvcU1vszIhGKtsrCZnQGBF8xbb1MVBIPXybyLq9rA
AjqTaLS1VPv98mVMeNsGq/ecIL1uW65JKc12GOQe22KEE6gDyy4=
=SFwv
-----END PGP SIGNATURE-----
pgphipms1rWEY.pgp
Description: PGP signature
--- End Message ---
