On Mon, 16 Dec 1996, Matthew Ritchey wrote: - Ok, one of my coders installed improved_edit.c, the patch. He - had to do it manually because our Circle code has been modified so - greatly, that it's almost unrecognizable to be circle. After that he - also installed tfiles_editor.c, also the patch. It seems to be working - except for medit. Since then, we have been crashing when using medit - without fail. I have tried to track this down myself, but I am looking - for a better coder out there to help me with this problem. Here's what's - up: You edit a new mob, ok.. looking good. It lets you edit it etc. - (BTW: Using Oasis). When you get prompted, as you're leaving medit, to - save the mobile, you type: yes you crash. Gdb produces the following: <snip> - I have spent the last week trying to track this down, so if anyone has - any suggestions, I would love some assistance on this. I have the following suggestions: 1) Spend some time leanring the finer points of GDB. It's a very useful tool once you get the hang of it, and it's got a lot of built in help for a unix utility. 2) Track down the coder(s) who modified your mud so greatly that it became unrecognizeable as circle. This is probably a simple fix for someone as familiar with circle as they must be. 3) Reread doc/license.doc and give credit where credit is due (ie: in your login screen) Quick crash course in gdb: *note that I'm not the least bit familiar with either of the patches you're using. When you get gdb output like you posted, it's not much help, or at least it's never been useful to me. It really doesn't tell you anything except for the fact that the code was trying to free memory that it shouldn't be (like freeint the same memory twice). When you run into these problems, you have to be intimate with your code. Find the function most likely to be the cause of the problem. In your case it should be very easy, since you can duplicate the problem with a specific procedure. You need to look for a function that saves the mob just edited, eithger to memory, or disk, or both. Load up gdb and run circle under gdb. > gdb bin/circle (gdb) run If the function you suspect is called save_mob, you should set a breakpoint at that function. <ctrl-C> <-- to suspend circle and return control to gdb (gdb) break save_mob In another window or on another terminal, telnet to localhost port 4000, and save a mob. The mud will lock up because gdb hits the breakpoint and takes control. Now you can use the gdb "step" command to step through each line in that function. As you're stepping lines, use "print" to print out any variables you encounter to make sure they seem normal. Keep an eye out for null pointers. With some patience you'll eventually find the exact line that causes the segfault. I think I posted a much better gdb primer to the list a couple months ago but I can't find a copy of it. Maybe that was someone else. Sam +-----------------------------------------------------------+ | Ensure that you have read the CircleMUD Mailing List FAQ: | | http://cspo.queensu.ca/~fletcher/Circle/list_faq.html | +-----------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/18/00 PST