Any problems with malloc on OS 4.1?

Barry Margolin think!barmar at bloom-beacon.mit.edu
Thu Mar 28 07:35:00 AEST 1991


In article <2122 at brchh104.bnr.ca> dale at dandelion.ci.com (Dale Gallaher) writes:
>The most likely problem is very clearly stated in the Sun sbrk man page,
>and I quote
>
>"WARNINGS
>     Programs combining the brk() and  sbrk()  system  calls  and
>     malloc()  will not work.  Many library routines use malloc()
>     internally, so use brk() and sbrk() only when you know  that
>     malloc() definitely will not be used by any library routine."
...
>The main thing I don't understand is how Sun can make two such basic
>functions in Unix incompatible within the same program.  I would really
>like to hear someone give a good explanation as to why this wasn't a
>ridiculous restriction to create.

This was discussed a week or so ago in comp.lang.c or comp.unix.questions
or something like that.  Most Unix implementations have this limitation,
but they don't all have the warning in their man pages.

The most common problem is that malloc() can't deal with another routine
calling sbrk() with a negative argument, which deallocates data space from
the process.  Malloc's arena data structures may include pointers into the
memory that is released, and it will get a segmentation violation when it
tries to indirect through one of them.

I also wouldn't be surprised if some malloc() implementations assume that
they are the only ones calling brk() or sbrk() to grow the data space, so
they use all the data space for the arena, rather than checking before
each call to sbrk() to see whether some other routine has allocated
intervening memory.

Barry Margolin, Thinking Machines Corp.
barmar at think.com
{uunet,harvard}!think!barmar



More information about the Comp.sys.sun mailing list