Any problems with malloc on OS 4.1?

[Dale Gallaher]

I got a slew of replies on this problem so I thought it would be helpful
if I brought people up-to-date on what I know.  There were many possible
causes of the problem that were proposed from overwrites in the
application code to known Sun bugs with patches for 4.1 and fixed in
4.1.1.  Thanks to all who replied.

First of all the problem does exist in O.S. 4.1.1 also so it is not fixed
there.  If anything it seems to be a little more frequent in O.S. 4.1.1.
As far as overwrites in the application code I think it is rather unlikely
since the code works fine on O.S. 4.0.3 or earlier and runs fine on all
other platforms.  Of course, it is always possible it is just some
overwrite the new Sun malloc is sensitive to.

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."

Since our application makes heavy use of both malloc and sbrk and the man
page claims programs doing this "WILL NOT WORK",  it seems that this is
very likely to be the problem.  Also, since the crash is always in putenv
which is a library routine which calls malloc, it is even more likely that
this is the problem.

A bigger problem for me is what to do now.  I have temporarily worked
around the problem by using my own version of malloc.  Unfortunately,
maintaining our own malloc could be a problem with future Sun releases for
different reasons. The use of sbrk is essential to the performance of the
application due to its memory management algorithms.  It seems I am kind
of stuck with my own malloc for now.

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.

Dale Gallaher					Cognition Corp.
dale at dandelion.ci.com				
(508)667-7900 x121				Billerica, MA