home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / aix / 8969 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  1.8 KB
  1. From: chan@hpfcmgw.FC.HP.COM (Chan Benson)
  2. Date: Tue, 18 Aug 1992 21:47:19 GMT
  3. Subject: Re: Re: Debuging Segmentation Violation Fault
  4. Message-ID: <9770001@hpfcmgw.FC.HP.COM>
  5. Organization: HP Fort Collins, CO
  6. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!hpscdc!hplextra!hpfcso!hpfcmgw!chan
  7. Newsgroups: comp.unix.aix
  8. References: <1992Aug14.121619.26071@watson.ibm.com>
  9. Lines: 29
  10.  
  11. > |>      I have this HUGE C program (20,000 lines). Everything worked fine
  12. > |> until the other day I added a few (about 10) lines to it. Then all of a sudden,
  13. > |> it keeps giving me this "segmentation violation". I ran "dbx" to see if I can
  14. > |> get some clue, it gave me something like:
  15. > |>
  16. > |> segmentation violation in malloc_y at 0xd00d43f0
  17. > |> 0xd00d43f0 (malloc_y+0x2a8) 7c7c45aa       stsi   r3,r28,0x8
  18. > |>
  19. > |>      From these two lines, all I can guess is that the fault is related to
  20. > |> "malloc". But "malloc" is used more than dozens of times throughout the
  21. > |> program, how am I supposed to know "who steps on whose toe and where".
  22. > |>
  23. > |>      I am desperate. Could someone tell me what other things I should do
  24. > |> beyond these two lines? Or maybe what books or manuals should I read to get
  25. > |> more information? What do those address-like (?) numbers all mean?
  26. > ...
  27. > 
  28. >   Usually malloc fails when it can't honor your request for storage.
  29. > i.e. you've requested a huge amount of memory (or even worse, a
  30. > negative amount--which I believe translates into a huge amount as
  31. > well!).
  32.  
  33. Nice try, but if malloc is giving a segmentation violation that usually
  34. means that the program wrote beyond the boundary of a previously malloc'ed
  35. area (thus trashing malloc's allocation info). These bugs are difficult
  36. to find without a debug version of the malloc library.
  37.  
  38.             -- Chan Benson
  39.             HP Fort Collins
  40.