home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / os2 / programm / 4307 < prev    next >
Encoding:
Internet Message Format  |  1992-08-18  |  2.9 KB
  1. Xref: sparky comp.os.os2.programmer:4307 comp.lang.c:12491
  2. Path: sparky!uunet!wupost!zaphod.mps.ohio-state.edu!sdd.hp.com!swrinde!gatech!news.ans.net!ans.net!db3l
  3. From: db3l@ans.net (David Bolen)
  4. Newsgroups: comp.os.os2.programmer,comp.lang.c
  5. Subject: Re: malloc causes a segmentation violation!?
  6. Message-ID: <1992Aug18.170550.66326@ans.net>
  7. Date: 18 Aug 92 13:07:04 GMT
  8. References: <1992Aug18.143135.6259@cc.tut.fi>
  9. Sender: news@ans.net (News Administrator)
  10. Organization: Advanced Network & Services, Inc. - Elmsford, NY
  11. Lines: 48
  12. In-Reply-To: mn87504@cs.tut.fi's message of Tue, 18 Aug 92 14: 31:35 GMT
  13.  
  14. In article <1992Aug18.143135.6259@cc.tut.fi> mn87504@cs.tut.fi (Naatula Mika) writes:
  15.  
  16. >Sometimes my program causes a segmentation fault. If I drive it with
  17. >CVP I can find out (from calls sequence) that the error was caused by
  18. >malloc. To be exact, malloc calls an internal(?) function named
  19. >_searchseg() that fails. Any ideas what this function might be?
  20. >
  21. >(...)
  22. >
  23. >My program uses a lot of dynamic memory allocation, but I am quite
  24. >sure that there is no bugs in my code. I have spent two days checking
  25. >out the memory allocation of this program.
  26.  
  27. I'd go back and spend some more time looking.  This very much sounds like
  28. something in your program used and errant pointer and trashed some of the
  29. memory control blocks used by the C compiler's memory allocation routines.
  30. The program only dies when you next try to do a malloc and the C compiler
  31. needs to scan for free space - the corrupted internal pointers cause the
  32. trap.
  33.  
  34. Dynamic memory problems are very subtle and hard to track.  Two days might
  35. only be a fraction of the time necessary to locate such a bug - I know I've
  36. spent a significantly longer time tracking down such bugs in the past.
  37.  
  38. Some things that can help is to dump debugging output for every allocation
  39. and free operation and ensure that everything matches.  Also - there are
  40. some libraries around (I'm not positive where - maybe someone else can
  41. help?) that replace the standard allocation calls, and set up signature
  42. areas around the allocated memory to help you track down the piece of code
  43. that is munging the wrong memory.
  44.  
  45. Alternatively, if you can somehow replicate a sequence of steps that causes
  46. the problem (not always possible), then you can scrutinize the code path
  47. that those steps take to see if you can find an uninitialized pointer, memory
  48. used after freeing, fencepost errors (ie: going 1 past the end of an array),
  49. etc..
  50.  
  51. Probably not what you wanted to hear - but I think you'll probably find the
  52. root of this problem in your code somewhere...
  53.  
  54. --
  55. -- David
  56. --
  57. /-----------------------------------------------------------------------\
  58.  \              David Bolen             \  Internet: db3l@ans.net      /
  59.   |   Advanced Network & Services, Inc.   \   Phone: (914) 789-5327   |
  60.  / 100 Clearbrook Road, Elmsford, NY 10523  \   Fax: (914) 789-5310    \
  61. \-----------------------------------------------------------------------/
  62.