Segmentation fault with other mods
I’ve been unable to run a listen server with etpub/nq/nitmod with latest etl (jaymod/silent/legacy are fine).
It seems the game crash at soon as the listen server is started.
Backtrace when launching etpub:
Program received signal SIGSEGV, Segmentation fault. 0x080abae4 in Cvar_Register (vmCvar=0xf6f41b80 <g_log>, varName=0xd4ec9056 "g_log", defaultValue=0xd4ec8ccb "", flags=1) at /home/remy/dev/etlegacy/src/qcommon/cvar.c:1511 1511 vmCvar->handle = cv - cvar_indexes; (gdb) backtrace #0 0x080abae4 in Cvar_Register (vmCvar=0xf6f41b80 <g_log>, varName=0xd4ec9056 "g_log", defaultValue=0xd4ec8ccb "", flags=1) at /home/remy/dev/etlegacy/src/qcommon/cvar.c:1511 #1 0x080c3ad3 in SV_GameSystemCalls (args=0xffffb454) at /home/remy/dev/etlegacy/src/server/sv_game.c:409 #2 0x08092d06 in VM_DllSyscall (arg=3) at /home/remy/dev/etlegacy/src/qcommon/vm.c:317 #3 0xd4e6b9b1 in trap_Cvar_Register () from /home/remy/.etlegacy/etpub/qagame.mp.i386.so #4 0x00000003 in ?? () #5 0xf6f41b80 in ?? () from /usr/lib32/libglib-2.0.so.0 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) quit
#3 Updated by IR4T4 almost 5 years ago
Seems memory related - other cvars were registered before ... there is no special in var g_log.
I’ve just realized this tiny difference in the count of cvars:
gamename: etpub gamedate: Jun 28 2010 412 cvars in use.
gamename: legacy gamedate: Dec 31 2014 190 cvars in use.
#4 Updated by Spyhawk almost 5 years ago
- Priority changed from Normal to Low
- Target version changed from 2.72 to 2.78
I actually cannot reproduce with the official static 2.71a, but I can reproduce it when compiling 2.71a by myself.
The issue is thus on my end, maybe related to Arch or dynamic linking.
#11 Updated by Spyhawk over 4 years ago
The issue isn’t due to Mesa 10.4, but to Freetype 2.5.5 when linked dynamically. The 2.5.5 update occurred on 2014-12-30 upstream and 2015-01-01 on my machine.
Setting BUNDLED_LIBS=1 and BUNDLED_FREETYPE=1 solves the issue. Both static and dynamic versions are 2.5.5 - this is strictly a dynamic compilation issue.
I also checked that the few extra Arch patches aren’t responsible for this issue (same issue with recompiled vanilla freetype).
Edit: According to Ensi:
< Ensiform> #751 is probably related to https://github.com/ioquake/ioq3/commit/de1840a23a1d1ec0a92e6317c197da53d47503fe
but of course this is not something you could fix without fixing etpub or other mods (this commit itself is
broken as it changes the cvar string names themselves though)
< Ensiform> see https://github.com/ioquake/ioq3/commit/4eb569b706ff03a6a6225409d16b9726bab1f19d / https://github.com/ioquake/ioq3/commit/b5074539ae797f94378b0bca086cd8a39461a302
essentially change the cvar variables but not the config names
This is most probably related, but doesn’t explain why Legacy runs with the same "bug" in the qgame code and isn’t something we can fix for other mods either.
#15 Updated by gaoesa over 4 years ago
Changing variable names is of course not a proper fix to a bug that shouldn’t exist. On the part of the mod library files, this and future name clashes can be avoided by setting the default visibility to hidden in GCC (-fvisibility=hidden) and using:
#if __GNUC__ >= 4 #pragma GCC visibility push(default) #endif ... #if __GNUC__ >= 4 #pragma GCC visibility pop #endif
around the vmMain functions. Maybe there was another function that needed this too, but I don’t remember. That resolves it in regards to the mod, but not if the libraries start clashing against each others. Of course, running strip is also good for the binaries.