bug in malloc() under OS 3.3

[Al Globus]

Todd Plessel writes regarding a bug in SGI OS 3.3 malloc():

>  * ulimit(3, 0) returns a bad value (about 800MB) but more importantly,
>  * malloc() allows up to about 500MB to be allocated!
>  * But when this data is actually filled, the program gets killed after
>  * about 75MB.

Chris Wagner responds:

We permit a process to allocate up to MAXUMEM of virtual space -
allowing a user for example
to alloc sparse matrices, or fork a large process. Only if the process
USES all the memory, then
we need a place to store it (swap space) If there is not enough swap
space, the process
is killed.  To avoid a process getting killed, reduce the maximum size
permitted.


This answer leaves the programmer who needs a lot of memory up the
proverbial creek without a paddle.  The programmer needs to know
exactly when he runs into the memory limitations of the machine so
that appropriate action can be taken.  Todd's code (I work with him)
does the right thing when malloc() returns 0, and he is able to
recover and let the user try something else.  Without any indication
that memory has run out the program simply crashes and the user
loses their work.  This is totally unacceptable.

There must be some straightforward way for the programmer to know,
for sure, whether the memory just allocated is really available or
not.  Setting the per-process limits is not sufficient since virtual
memory is a system wide resource.

The bottom line is that my users
cannot use my software on IRIS 3.3 to examine thier data because I
can't tell when they've run out of memory because malloc() is
lieing to me.

The malloc() man page says: " malloc returns a pointer to a block of at least
size bytes".  It does not say "a pointer to a block of 0 to size bytes,
depending on what else is going on in the system."