MOO-cows Mailing List Archive


SERVER:memory allocation bug in 1.8.0p5

The MOO server has wrappers for memory allocation called mymalloc and
myfree.  On a production MOO server these are usually just tracking the
number (and with gnumalloc the total size) of allocations made for
different data types.  With the FIND_LEAKS option turned on, these
wrappers manipulate the pointers given to them by the actual malloc/free
calls and it becomes important that all of the memory allocated by
mymalloc is freed with myfree.  I just stumbled across a case where
memory was acquired with mymalloc but freed with free.  People using
gnumalloc (and the @memory command) probably see this as an apparent
memory leak in pattern allocation.  Otherwise a server without FIND_LEAKS
is totally unaffected.

So, to repeat, unless you have FIND_LEAKS turned on, this isn't affecting
you at all, except possibly in the output of @memory.  If you DO you
are probably seeing the MOO panic occasionally with random segvs due to
malloc arena corruption (unless you're running FreeBSD, which has an
allocator which actually detects this (!)).

So with all that to keep people from panicking and mailing me questions,
the fix is in free_pattern in pattern.c:

*** ../MOO-1.8.0p5/pattern.c	Wed Feb 12 20:58:03 1997
--- ./pattern.c	Wed Feb 12 20:57:52 1997
*** 169,175 ****
      if (buf) {
! 	free(buf->fastmap);
  	myfree(buf, M_PATTERN);
--- 169,175 ----
      if (buf) {
! 	myfree(buf->fastmap, M_PATTERN);
  	myfree(buf, M_PATTERN);

Home | Subject Index | Thread Index