On Thu, 30 Nov 2000, RJ Bean wrote:
> if (ch->player.short_descr)
> free(ch->player.short_descr);
>
>on the free statement- the mud crashes.
Welcome to random memory corruption. :)
Add '-lefence' to the end of 'LIBS' in Makefile and boot in mini-mud mode
(very important!) to track it down. Alternatively, you can do:
MALLOC_CHECK_=1 bin/circle
to get warnings instead of crashes. If you're not using some sort of Unix
(and Linux glibc2 for the second one), then you'll have to try something
else. Sometimes moving the 'free(ch->player.short_desc)' to random places
in the MUD would help. If you crash immediately on that new
(wrongly-placed) free() call, then you've already hit the bug there,
otherwise you crashed because of the debugging check so move it and trying
again...
The third method worked on the 'world[-1]' bug from the castle.c special
procedure in the bpl13-14 days. Electric Fence (-lefence) is nice but if
you don't run in mini-mud mode, I hope you have a lot of RAM or swap space.
>I was musing on that perhaps its because I'm using a C++ compiler and the
>free (and malloc) statements are from C. Anyone have an similar
>experience with this before? I am perplexed...
If that was true, then I suspect you'd also have problems with:
fopen
fclose
fscanf
printf
fprintf
gettimeofday
accept
write
read
...etc...
(No, it has nothing to do with it unless your C++ compiler just happens to
be broken and produce bad code, but that's independent of function calls.)
--
George Greer | If it's about the CircleMUD mailing list,
greerga@circlemud.org | mail owner-circle@post.queensu.ca instead.
--
+---------------------------------------------------------------+
| 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 : 04/11/01 PDT