b5494 Segmentation Fault

[QwazyWabbit]

r1q2ded seg. faults at startup. Mod is LOX 1.12.8 already proven to work with b5240, no library signon banner no library version load information no indication that server got past initialization. Same command line as the one used to start b5240.

from gdb session:

(gdb) run
Starting program: /home/geoff/quake2/r1q2ded +set game lox +set deathmatch 1 +set dedicated 1 +set maplist 1 +exec server.cfg
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x00572024 in _int_malloc () from /lib/tls/libc.so.6
(gdb) backtrace
#0  0x00572024 in _int_malloc () from /lib/tls/libc.so.6
#1  0x0057110d in malloc () from /lib/tls/libc.so.6
#2  0x08050340 in ?? ()
#3  0x00033ad0 in ?? ()
#4  0xbff037c8 in ?? ()
#5  0x00560cef in fread () from /lib/tls/libc.so.6
#6  0x08052a6f in ?? ()
#7  0x00033ac0 in ?? ()
#8  0x00000009 in ?? ()
#9  0x00000001 in ?? ()
#10 0x0a217db0 in ?? ()
#11 0xbff0889c in ?? ()


Suggestion: Have r1q2updater back up the previous binary automatically. How about a nice "cp r1q2ded r1q2_bXXXX" (in Windows: "copy r1q2ded.exe r1q2ded_bXXXX.exe") to backup the older known version number to a file so when this kind of thing happens it's already covered. I am already doing this manually but an automatic backup would seem to be prudent in an automatic updater.

[QwazyWabbit]

Nevermind.  This looks like a library compatibility problem. I rebuilt the binary from source and it runs ok.

[R1CH]

Did the R1Q2 segv handler not even hit? Definitely looks like some kind of library issue if it never even got started. I notice the /lib/tls/ stuff, I've had a few systems where that version of libc causes issues with binary compatibility.

[QwazyWabbit]

No, what you see is what I got no reg dump or info at all. If you want to send me a debug build I might be able to gdb some more details. The server is my test server, a dual P-Pro machine that runs Fedora Core 1 SMP much slower than it used to run Win2k Pro SMP. I use it to build and test my LOX code for our live servers and distros. I built a debug version of your code on it and it doesn't fail. I am not a gdb guru either so debugging in that environment is not a treat. I am not surprised it's a lib function failure since there are so many non-downlevel compatible builds of Linux out there that it's a wonder it hangs together at all. Linux is going to kill itself if they don't clean up the compatibility issues. This machine won't update itself either, the Fedora Updater crashes when I try to use it and it took 3 or 4 hours to build a new system when it destroyed the installation I had been using successfully for months. What I really need is a multi-boot P4 with oodles of HD to play on so I can image the thing before every update. I just don't have the time to keep up with every patch that comes out.

[R1CH]

Yeah, Fedora is where I've had other reports come from. That libc/tls thing is usually to blame, it breaks binary compatibility. Odd that previous build worked though, perhaps something in the GCC4 compile is causing it.

I'd also recommend Virtual PC from Microsoft, I use it to make the R1Q2 binaries from a Slackware 7 setup, sure makes it easier than doing it remotely or having to dual boot constantly!

[Nick]

I had this [similar] problem at work...  I updated GLIBC on my Linux dhcp/dns boxes, and it broke an application big time.  I didn't suss it, but my colleagues in Montreal did.

Have a read here on the problem:

http://people.redhat.com/drepper/assumekernel.html

Nick