home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / os2 / programm / 4323 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  2.7 KB
  1. Xref: sparky comp.os.os2.programmer:4323 comp.lang.c:12522
  2. Newsgroups: comp.os.os2.programmer,comp.lang.c
  3. Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!darwin.sura.net!Sirius.dfn.de!zrz.tu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!news.funet.fi!mn87504
  4. From: mn87504@cs.tut.fi (Naatula Mika)
  5. Subject: Re: malloc causes a segmentation violation!?
  6. Message-ID: <1992Aug19.155648.6210@funet.fi>
  7. Sender: usenet@funet.fi (#Kotilo NEWS system )
  8. Nntp-Posting-Host: kaarne.cs.tut.fi
  9. Organization: Tampere University of Technology
  10. References: <1992Aug18.143135.6259@cc.tut.fi> <3dfy6bq@rpi.edu>
  11. Date: Wed, 19 Aug 1992 15:56:48 GMT
  12. Lines: 51
  13.  
  14. As a responce to my article (Bill Maniatty) writes:
  15. >Possibility - Bug is yours (very small I'm sure, but still possible)
  16.  
  17. Yes that is true. People generally tend to think that they make no
  18. errors...
  19.  
  20. >Can you compile and link with a debugging version of malloc?
  21. >    (Some environments provide for one).
  22. >
  23. >You might want to count number of mallocs/frees and trap on a free when
  24. >number malloced < number freed.
  25.  
  26. I made my own Smalloc and and Sfree functions which call the standard
  27. malloc and free. I save in a table the allocated pointers and compare them
  28. before free is called. This is an easy way to catch many possible errors.
  29.  
  30. >Verify that no access is made beyond the end of malloced structures.  Typically
  31. >malloc creates a linked list looking like the following:
  32. >
  33. >    --------------------------------------------
  34. >    | malloc info a | user data | malloc info b|
  35. >    --------------------------------------------
  36. >
  37. >The malloc info contains ptrs to other blocks in free/use chain, size information,
  38. >etc...  Please note that malloc info may be found at one end or the other of
  39. >the structure, and writing beyond the end of structure would trash it and corrupt
  40. >the heap.
  41.  
  42. Yes. That was the kind of information I was looking for. After my own
  43. Smalloc and Sfree functions writing beyond allocated space is the only
  44. possible cause of segmentation faults.
  45.  
  46. I thought that OS/2 could detect writes to non-allocated areas and
  47. give me a segmentation fault right away.  Like it usually does. 
  48.  
  49. But back to the problem. I still have not found the actual spot of
  50. the error, but I know what the reason is. (My program is a large one) 
  51. In my own Smalloc when I call malloc I allocate the requested space
  52. plus one and the segmentation fault is gone! ( p=malloc(size+1) )
  53.  
  54. Like many times before, the error was made by user! 
  55.  
  56. Thanks to all of you who have helped me with this.
  57.  
  58. >|    maniattb@cs.rpi.edu - in real life Bill Maniatty
  59. -- 
  60.              __   | Mika Naatula            Email: mic@cc.tut.fi
  61. |\ //| ||  //  \  | Lindfrosinkatu 8 A 11          mn87504@cs.tut.fi
  62. | \/ | || ||      | 33720 Tampere, FINLAND
  63. |    | ||  \\__/  | 931-185 993
  64. -- 
  65.