home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / c / 11439 < prev    next >
Encoding:
Text File  |  1992-07-22  |  2.2 KB  |  50 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!wupost!zaphod.mps.ohio-state.edu!uunet.ca!hyper.hyper.com!hurst
  3. From: hurst@hyper.hyper.com (Graham Hurst)
  4. Subject: Re: good memory allocation strategies?
  5. Message-ID: <1992Jul22.172111.2646@hyper.hyper.com>
  6. Summary: Dynamic memory allocation is unsafe with default SGI kernel
  7. Keywords: SGI kernel
  8. Sender: hurst@hyper.com (Graham Hurst)
  9. Reply-To: hurst@hyper.com (Graham Hurst)
  10. Organization: HyperCube Inc.
  11. References: <1992Jul21.214115.28569@tamsun.tamu.edu>
  12. Date: Wed, 22 Jul 1992 17:21:11 GMT
  13. Lines: 35
  14.  
  15. In article <1992Jul21.214115.28569@tamsun.tamu.edu> tsmith@cs.tamu.edu writes:
  16. ...
  17. >I am working on a moderate size (~10000 lines so far) system on an SGI
  18. >workstation running UNIX system V.3, and I am wondering about some
  19. >memory allocation issues. [Rest deleted]
  20.  
  21. Beware of using memory allocation on SGI computers!
  22.  
  23. We recently discovered a "feature" of the default SGI kernel that makes
  24. dynamic memory allocation unreliable - it never turns down a request for
  25. memory!
  26.  
  27. Since IRIX 3.3.2, the default SGI kernel will cause malloc/realloc
  28. (via sbrk) to return a non-zero pointer even if the requested memory size is
  29. greater than the sum of physical memory and swap space! If your app tries
  30. to use enough of this memory, the kernel sends a SIGKILL to kill your app
  31. and puts a message on the console about running out of swap space.
  32.  
  33. I know (but don't agree with) SGI's reasons for making the change in their
  34. kernel, and I know non-portable workarounds that help (including reconfiguring
  35. the kernel). Even if you roll-your-own memory management, many GL calls use
  36. malloc.
  37.  
  38. SGI told me that Mach and OSF/1 act the same way (i.e. allow fork/exec/sbrk
  39. requests greater than swap+physical). Can anyone confirm?
  40.  
  41. This behaviour precludes portable and otherwise robust software (employing
  42. the good coding practice of checking the return value of malloc) from
  43. executing reliably on SGIs. I believe it is also at odds with the ANSI C
  44. standard (can't quote it directly, but K&R II suggests if one gets a non-zero
  45. pointer one can use the memory).
  46.  
  47. Graham Hurst
  48. Hypercube Inc, 7-419 Phillip St, Waterloo, Ont, Canada N2L 3X2 (519)725-4040
  49. internet: hurst@hyper.com
  50.