home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / sun / admin / 10666 < prev    next >
Encoding:
Internet Message Format  |  1993-01-23  |  2.3 KB
  1. Xref: sparky comp.sys.sun.admin:10666 comp.sys.sun.apps:3062 comp.sys.sun.misc:6441
  2. Newsgroups: comp.sys.sun.admin,comp.sys.sun.apps,comp.sys.sun.misc
  3. Path: sparky!uunet!cs.utexas.edu!uwm.edu!linac!att!mcdchg!laidbak!tellab5!sdc!scott
  4. From: scott@sdc.com (Scott Dunbar)
  5. Subject: Re: SEGV inside malloc() - This shouldn't happen!
  6. Message-ID: <1993Jan22.145011.8058@sdc.com>
  7. Originator: scott@minnie
  8. Sender: news@sdc.com (Netnews administrator)
  9. Nntp-Posting-Host: minnie
  10. Organization: sdc
  11. References: <mike.727636808@sdd.comsat.com> <MANN.93Jan21131125@emma.la.asu.edu>
  12. Distribution: na
  13. Date: Fri, 22 Jan 1993 14:50:11 GMT
  14. Lines: 31
  15.  
  16.  
  17.  
  18. In article <MANN.93Jan21131125@emma.la.asu.edu>, mann@emma.la.asu.edu (Mark Mann) writes:
  19. > In article <mike.727636808@sdd.comsat.com> mike@sdd.comsat.com (Mike Stennett) writes:
  20. > >  I am currently porting a program to a SparcStation 2 running SUN/OS 4.1.2.
  21. > >  The program is written in C, Pascal, and Fortran.  I am using all SUN 
  22. > >  compilers.  My problem is I am getting segmentation faults within malloc.
  23. > >  Now I have been writing C programs for 4 years and know that malloc should
  24. > >  never cause a segmentation faults.
  25. > >  [...]
  26. > 
  27. > I have found that malloc() will fail with a segmentation fault when you
  28. > trash its tables.  This usually happens when you write beyond the end
  29. > of an array.  You haven't written out far enough to cause a segmentation
  30. > violation yourself, but just far enough to make garbage out of malloc()'s
  31. > tables. So... next time you call malloc() and it tries to access the
  32. > garbage you created... SEGV or somesuch.
  33.  
  34.     I agree fully.  If you trash the heap, anything is possible with malloc()
  35. and free().  I would recommend the Purify product or something like it to track
  36. down these types of problems.  With this it should take you very little time to
  37. find anywhere that you are writing over the end or before the beginning of a block
  38. of allocated memory.  Purify helped me find many errors on a system that was
  39. ported from MS-DOS.  The MS-DOS boxes would sometimes go into never-never land
  40. but basically were ok.  The Suns SIGSEGV'd or SIGBUS'd all over the place.
  41.  
  42.     Good luck.
  43. -- 
  44. scott dunbar                             Systems Development Corporation
  45. scott@sdc.UUCP                           Chicago, IL
  46. ..uunet!tellab5!sdc!scott         312 739 1111
  47.