On Mon, 8 Jul 1996, Rasmus 'Con' Ronlev wrote: > Anyway, I'm slightly satisfied that it seems, as if I got the most 'crash > bugs' out of the mud I code on, unfortunately I'n receiving those damn > "TICKS NOT UPDATED" automatic shutdown things now. It's my understanding > that all causes to such a 'bug' should not exist in the straight > circlemud code (the mud is based on bpl8). The mud has been pretty > heavily modified though, and thus the most probable cause for this 'tick > error' would be some part of the code that I've added. > In the proccess of debugging the mud I used some of the GDB scrips that > were strewn arround here lately, and made a few modifications to the > interpreter.c, so that I get the LAST executed command, the room in which > is was executed, the arguments, and the players name. All this functions > nicely, but ermm.. It's helped me to debug the few real 'crashbugs' which > were difficult to find in anything but constant play, but now I'm faced > with the reality, that I can't figure out whats wrong.. *sulk* If you can make the mud lock up at will, or can wait around watching for it to lock up, you can manually load the mud under gdb, and when the mud locks up, hit ctrl-c in you gdb window to interrupt the mud. This will allow you to see exactly where the endless loop is. Btw, if you're using obuild .06, there seems to be a problem that comes and goes where saving objects causes an endless loop in the code that writes extra descriptions. If you're using obuild check your object directory for very long *.obj.back files. I'm currently working on a fix for this. Sam
This archive was generated by hypermail 2b30 : 12/07/00 PST