On Thu, 27 Nov 1997, George wrote:
> On Thu, 27 Nov 1997, Rasmus Ronlev wrote:
>
> >I was certain I had gotten rid of all problems with medit crashing (and a
> >lot of other *edit's *snicker*), at least I hadn't seen it happen on
> >Exiled. So, now a weeks time or so ago, when some builder started working
> >with the olc online it crashed on him when he used medit, and selected to
> >save the changes he just did.
>
> It's only when saving a newly created mobile internally that it shifts
> memory around a lot.
>
> >After playing a little with the mob edit portion of the olc I found out
> >the olc only crashed when adding a NEW mobile and selecting to save this.
> >As the Oasis-knowledgable of you probably know, the crash happens when the
> >medit_save_internally() function free()'s mob_index and mob_proto (tried
> >commenting either free() out, and crashed on both occasions.
>
> I think you only have you comment out the one on top.
Well, the reason for me posting this mail is the fact, that I'm stunned :P
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...
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 ?
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 ?
> 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.
> 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.
*sigh*
Regards,
Rand
.d
--
Rasmus Ronlev DOEK'94 http://www.econ.cbs.dk/~raro94ab
IT-Advisor mailto:raro94ab@student.econ.cbs.dk
B.Sc. Computer Science and Business Administration
Stud. M.Sc. Computer Science and Business Administration
+------------------------------------------------------------+
| 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