home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / aix / 8120 < prev    next >
Encoding:
Text File  |  1992-07-23  |  1.5 KB  |  41 lines
  1. Newsgroups: comp.unix.aix
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!news.cso.uiuc.edu!void.ncsa.uiuc.edu!marca
  3. From: marca@void.ncsa.uiuc.edu (Marc Andreessen)
  4. Subject: Re: SUMMARY: dbx problems
  5. References: <1992Jul23.202224.29736@ief.itg.ti.com>
  6. Message-ID: <BrvAFJ.6oM@news.cso.uiuc.edu>
  7. Sender: usenet@news.cso.uiuc.edu (Net Noise owner)
  8. Organization: University of Illinois at Urbana
  9. Date: Fri, 24 Jul 1992 00:23:41 GMT
  10. Lines: 29
  11.  
  12. block@ief.itg.ti.com (Bucky Block) writes:
  13. : 
  14. : Thanks to Gary Keim <gk5g+@andrew.cmu.edu> who provided me
  15. : with the MALLOCTYPE 3.1 fix. After I set that variable dbx
  16. : worked ok (not great, but ok). 
  17. : 
  18. : Funny thing, my application dies if I don't use the 3.1 malloc, 
  19. : does anyone know what the difference is between the two mallocs?
  20.  
  21. Your application is mishandling memory.  The 3.2 malloc is much more 
  22. stringent about allocating the proper amount of memory, while the 3.1 
  23. malloc would round your request up to the next power of two (in bytes, 
  24. I believe).  Also, 3.1 malloc would clear all memory it allocated to 0; 
  25. 3.2 malloc does not.  (Normally, malloc isn't supposed to do this -
  26. but calloc is.)
  27.  
  28. Because so many applications use memory incorrectly but work with the
  29. overly liberal 3.1 malloc, IBM decided to continue to supply it with 3.2;
  30. thus, the MALLOCTYPE variable.
  31.  
  32. Hope this helps,
  33.  
  34. Marc
  35.  
  36. -- 
  37. Marc Andreessen
  38. Software Development Group
  39. National Center for Supercomputing Applications
  40. marca@ncsa.uiuc.edu
  41.