Path: utzoo!attcan!uunet!samsung!sdd.hp.com!elroy.jpl.nasa.gov!ames!eos!amelia!globus From: globus@nas.nasa.gov (Al Globus) Newsgroups: comp.sys.sgi Subject: Re: bug in malloc() under OS 3.3 Message-ID: Date: 19 Jul 90 21:29:53 GMT References: <7401@amelia.nas.nasa.gov> <10578@odin.corp.sgi.com> Sender: news@amelia.nas.nasa.gov Organization: Applied Research Office, NASA Ames Research Center Lines: 42 In-reply-to: jwag@moose.asd.sgi.com's message of 19 Jul 90 02:24:25 GMT 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."