On Thu, 27 Nov 1997, Rasmus Ronlev wrote:
>On Thu, 27 Nov 1997, George wrote:
>
>As it is now, the memory wrapper I've created does not detect any parts of
>the mud code freeing parts more than once, or segments of or parts of
>other segments being freed wrongly, or twice or some such thing that would
>corrupt the memory, and specifically the mob_proto and mob_index...
There are many ways to crash besides freeing something twice. :)
>Is it not correct, that some part of the mud-code would have to FREE some
>part of the mob_proto or mob_index for the error to occur in the lines:
>
>free(mob_proto)
>free(mob_index)
>
>In the medit.c file ? I mean if the free() call makes the segmentation
>fault, would that not mean, that what is being freed has already been
>freed ? Or, that part of what is being freed has already been freed ?
Free() can crash because you overwrote the internal tables where it tracks
the memory allocated. Or because you smashed random memory or just because
it doesn't like where you put that last byte of data.
>My point here is, that at an earlier time, I had problems with the
>free_mobile() procedure, freeing some stuff that it shouldn't. But that
>would only show up after a short time, when the next attempt to free the
>memory was made. Here the mud crashed instantly, either on freeing
>mob_proto or mob_index, if I comment either of them out.
>
>Anyway, I also tried using the electric fence debugging library, and that
>didn't seem to find any errors either... So... Well... Does anyone have
>any ideas about what I should/could do, to find out if it's some other
>portion of the mud code, that's the reason for the segmentation fault, or
>some other problem ?
See my last section.
>> 2) When running CircleMUD in mini-mud mode it was crashing when creating a
>> new mobile, it turned out the be the King's Castle writing to
>> mob_index[-1],
>
>I ripped the castle.c out of the code, so that's not a problem, and I'm
>not running the mud in normal mode anyway :) However, I did change a fair
>deal of code, just not something that I beleave would harm the mob_proto
>or mob_index structures. Not to mention, I usually debug what I make of
>new changes to the code. So, I'm really very much in the void here. I
>expected gdb to be able to help with the electric fence malloc library,
>but that was about as usefull as any other initiative I've done so far.
Debugging tools aren't perfect. I debugged the code by moving a
free(mob_proto); around the code starting first at the olc code then
starting right after allocation and moving til it crashed. Then when I
isolated it in the special procedure library I went to find out just how it
was corrupting the memory.
>> So until I can be proven wrong (and I may very well be at some point), any
>> medit crashes are due to memory problems in other parts of your MUD. :)
>
>Right now I'd bet on it *grin* But ofcourse, there might be some sneaky
>memory fooker somewhere in the code I've added recently, that doesn't show
>up anywhere really, unless I free the mob_proto and mob_index tables.
So free them after parts of the code that you think would cause the
problem. Of course the MUD will crash when you do this but if it crashes
on that free you know the problem occured previous to it. If it crashes
later, yout know it's because you free()'d the mob protos :)
--
George Greer - Me@Null.net | Genius may have its limitations, but stupidity
http://www.van.ml.org/~greerga | is not thus handicapped. -- Elbert Hubbard
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST