Kras Kresh wrote: > > Recently I've been experiencing some unknown bug that when the mud > crashes i gdb the core file and i gives me the line of where the > game crashed > > #0 0x206c6f74 in ?? () That means that the seg fault actually caused the core dump to get messed up. What it also means is that you're in for a hell of a time troubleshooting the problem. My recommendation is to first compile your program with Electric Fence (efence) linked in and see if it provides any more help (it may or may not help). Don't post back and ask what's efence, it's been discussed before so search the archives first, then post back. Note that if you're system does not have efence it _is_ possible to download the source from http://www.perens.com/FreeSoftware/ and compile and link it as non-root. There are also other memory allocation debugging tools that may or may not help. If all else fails you will be stuck with getting into a real dirty gdb session setting breakpoints and trying to find the line where it crashes and get it to stop there _before_ it crashes. Don't ask me how to do this either, use the built-in help for gdb and other documents available online to figure this out (it's a real pain and a last resort, but it does work). Some things that will help are: Ask yourself what you changed between the last time you saw it working and the first time you noticed that it didn't work, focus your troubleshooting in these changed areas. Revert back your last one or two changes (more if neccessary and able), test to see if the problem is still there then apply changes back one at a time. Hopefully you have some method of reverting your changes back (CVS is the easiest and best if you've been using it, otherwise old backups, whatever you have available). Worst case scenario try to manually revert your changes back from memory (this is far from fool proof but it might be the only solution you've got). Try commenting out chunks of suspicious code (use #if 0/#endif not /* */ to do this as C does not work with recursive comments, but the #if preprocessor stuff works recursively). Ideas for the future: Use some kind of revision control system. I highly recommend CVS, but if you don't want to put in the time and effort to set up something like CVS the following while being rather rudimentary will work (though eventually it will probably end up requiring just as much, if not more time and effort than CVS)... Create a new file in the src directory called revisions.h. Whenever you add new code put a #define in this filewhich describes what you're adding, something like this... #define DIAGONAL_DIRECTIONS_SNIPPET 1 Then in any file that you're changing for the new code add a #include "revisions.h" and make your changes like this... #ifdef DIAGONAL_DIRECTIONS_SNIPPET /* New code goes in here */ #else /* Old code that you're replacing goes in here (if you're just adding code then leave out the #else part entirely) */ #endif Then if you need to revert that change all you have to do is take out the #define in revisions.h like this... #if 0 #define DIAGONAL_DIRECTIONS_SNIPPET #endif Then re-compile. If you ever want to add the code back in just change the 0 to a 1 on the #if line. Note that this rudimentary system is not entirely fool proof as it is possible to accidentaly tweak parts of t he code that you're not aware of and would not get covered by the #ifdef/#endif's that you're putting in. You should still back up if you're gonna use this system. Regards, Peter -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/05/01 PST