Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: think!barmar@bloom-beacon.mit.edu (Barry Margolin)
Newsgroups: comp.sys.sun
Subject: Re: Any problems with malloc on OS 4.1?
Keywords: SunOS
Message-ID: <2214@brchh104.bnr.ca>
Date: 27 Mar 91 21:35:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 34
Approved: Sun-Spots@rice.edu
X-Original-Date: Tue, 26 Mar 91 18:34:03 GMT
X-Refs:  Original: v10n54, Replies: v10n61
X-Sun-Spots-Digest: Volume 10, Issue 61, message 15
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

In article <2122@brchh104.bnr.ca> dale@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@think.com
{uunet,harvard}!think!barmar