Can we change Co-op a bit?

[QwazyWabbit]

yes, removing q2admin gets rid of whatever bugs are in that module but it does nothing for the bugs that exist inside the game dll itself. It just lets you get further into the game where you can work on those uncovered bugs.

[console]

yes, removing q2admin gets rid of whatever bugs are in that module but it does nothing for the bugs that exist inside the game dll itself. It just lets you get further into the game where you can work on those uncovered bugs.

I have to wonder...I'm loathe to defend q2admin much, since its codebase is indeed really crappy.  But on the other hand, q2admin does manage to run without crashing, for _months_, on numerous other mods on servers like vanilla, mutant, dm, railz, xatrix, ra2, sheridan, opentdm, ....

So the fact that coop is still crashing frequently, but less predictably without q2admin in the mix, suggests to me the possibility that the only really important bug we're after exists in the coop code.  If the coop bug is trashing memory, q2admin may just churn the heap more and trigger the crash sooner....

 . . .

I see that there exist patches to create a gcc with a bounds-checking option:

http://williambader.com/bounds/example.html

...hmm, they stopped making patches in 2005, looks like gcc has a builtin "-fbounds-check" flag now...

...GAH!  But the built-in version only supports Java and Fortran..


Oh well, anyway... One could certainly wrap whatever malloc/free calls are available to the game module with some simple extra data to catch overwrites / underwrites, as well as write some validation routines to walk various internal structures in Q2 to detect whether anything has been obviously stomped on... and do the usual "sprinkle calls to the validation routine throughout the code..."


Regards,

[peewee_RotA]

This probably sounds stupid but...

Are the additional crashes happening after unit 2? The words "hacky", and "power cube", are pretty much synonymous in the quake 2 code. If it's a memory issue, then it sounds like it has to do with not clearing everything at the end of a unit. The first thing that comes to mind is the fact that keys are handled "differently" in coop. Meaning that things like crosslevel triggers and keys used across a level are probably not cleaned up the same way.

[QwazyWabbit]

I prefer to debug in VC6's IDE and then deal with GCC after the fact but if there is a decent way to Bcheck the code then I am all for it. I am (slowly) getting better at KDE and GDB.

Regarding malloc, if there are any bare malloc() calls left in your version of q2admin you might want to follow R1ch's Q2 best-practices and always call gi.TagMalloc() from all the game DLL's.

All I know about q2admin is, like you, DM is always stable and I have gotten months of continuous operation of the server without crashes, even cascading GameCam over q2admin over LOX. I don't know what it is about coop but the only way I could get LOX coop to run for very long was to take q2admin out of the picture. GameCam over LOX in coop worked fine, at least in my somewhat limited tests.

Once you have a fairly stable (or even unstable) coop server up and you would like to enable spectator mode you can download a slightly fixed up version of GameCam here: http://www.windowmeister.com/lox (with source) which is the one I use on our LOX server. There was only one bug in Avi's original code where he called gci.dprintf after he had unloaded the dll. I think Avi Rozen's code is one of the best examples of Q2 mod coding style out there.

You might be able to spectate WallFly by letting him connect and issue a spectator 1 command to bump him up and out into the gamecam.

Per my earlier post, I found coop (3.21) failing inside q2admin with a smashed user command buffer but I simply don't have time right now to dig into it. I tested it with LOX 1.12.16 with similar results. I would love to be able to fix it once and for all but time is not available to me right now.