Need help with debugging new xatrix mod

[SquiSHeR]

Hello friends,

currently I am working on adding xatrix multiplayer code to the openffa mod by skuller in order to get a nice new xatrix game library for ffa. I doubt there are any xatrix players out there at the moment, but hopefully this way I can motivate ffa-server admins to add this gametype to their ffa games.

Unfortunately I have no c programming language knowledge (I write PHP code most of the time).

Nevertheless I managed to sucessfully merge the 3.20 xatrix gamelib code to the openffa code so that it even compiles without errors - yay . It was quite hard for me since skuller modified a lot code which deals with items and especially weapons - I had to readapt this changes onto the xatrix code aswell.
Xatrix items are displayed, can be picked up and the weapons seem to fire correctly. The only issue is with traps. Once I throw a trap and jump right into it, the server crashes with a memoryaccess error (no more details given).

Could someone of the more experienced Q2 mod developers help me with debugging? I have absolutely no idea how to debug a c library crashing issue. How can I get more informatin about the source of the error?

My current working state is available on github: https://github.com/Niehztog/openffa

Once I managed to fix this bug I plan to merge in more changes, first the 3.24 xatrix gamelibrary changes by knightmare and later even the q2plus/tastyspleen additions especially for ionripper and traps. This would make openffa a fully qualified alternative to the quake2plus implementation.

My motivation is to bring more attention to the mission packs. I think there is no reason to not have them in the baseq2 main gamelibrary code, since everybody has them, they add nice new variety to items, gameplay-style and weapons and they contain no new playing-modes which would justify excluding them to mod-subdirectories.

[|iR|Focalor]

Debugging? This looks like a job for... CAPTAIN SMARTASS!!! 

<span data-s9e-mediaembed="youtube" style="display:inline-block;width:100%;max-width:640px"><span style="display:block;overflow:hidden;position:relative;padding-bottom:56.25%"><iframe allowfullscreen="" scrolling="no" style="background:url(https://i.ytimg.com/vi/GihPc3PUorw/hqdefault.jpg) 50% 50% / cover;border:0;height:100%;left:0;position:absolute;width:100%" src="https://www.youtube.com/embed/GihPc3PUorw"></iframe></span></span><br /><a href="https://www.youtube.com/v/GihPc3PUorw" target="_blank" class="new_win">https://www.youtube.com/v/GihPc3PUorw</a>

But seriously... Yes, there are still a few Xatrix players. I dunno if he still gets online much, but Exterminader used to have a Xatrix server he rented from Quadz, dunno if he still does. But him, Debbie, and several others used to get on nightly for some Xatrix playing, and sometimes I'd swing through for a few maps if they were on. I'd certainly play it more if I saw other people were on.

[SquiSHeR]

I figured it out after hours of googling and watching debugging turorials 

I installed gdb on my dev machine and started the game with

Code: [Select]

gdb --args r1q2ded +set dedicated 1 +set game xatrix +set ip localhost +set port 27910 +exec server.cfg

then I told gdb where to look for the openffa source files and started the game

Code: [Select]

dir /home/devuser/openffa
run

Then after the crash happened I could clearly see some really helpful information

Code: [Select]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff66be73e in ClientObituary (inflictor=<optimized out>,
    attacker=<optimized out>, self=<optimized out>) at p_client.c:347
347             self->client->resp.frags[frag].suicides++;

the crash is fixed now 

I could use some help with testing though...

[QwazyWabbit]

I'll try to test on my PC and on my Linux but I don't care much for gdb. I'm so old and experienced and spoiled with visual studio that I'm useless on gdb.

Regarding debugging, the makefile in that repo is pretty tight and seems to be geared for optimization and release more than development. Remove the -fvisibility=hidden switch in line 30 and I think you'll see more symbols in the debugger. In line 22, consider also changing -O2 to -Og to prevent compiler optimization from screwing up the debugger. Processors these days are fast enough that you shouldn't see performance problems and you can change it back to O2 for your active servers.

Segmentation faults usually mean you've dereferenced a NULL pointer (very common in Q2 code) or a pointer that's pointing to something it shouldn't. This usually means the function that faulted was passed a bad pointer when it was called and you can trace up the call stack to see which function called it. Whether that means you have defend against it in the callee or not pass the bad argument in the caller will depend on what you see in the debug.