NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/unix/aix/8816

Text File | 1992-08-14 | 3.1 KB | 66 lines

Newsgroups: comp.unix.aix
Path: sparky!uunet!usc!wupost!sdd.hp.com!ux1.cso.uiuc.edu!news.cso.uiuc.edu!vista.atmos.uiuc.edu!davidw
From: [e-mail] (David Wojtowicz)
Subject: Re: Debuging Segmentation Violation Fault
References: <[e-mail]> <[e-mail]>
Message-ID: <[e-mail]>
Sender: [e-mail] (Net Noise owner)
Organization: Atmospheric Science at Univ of Ill at Urbana-Champaign
Date: Fri, 14 Aug 1992 15:21:30 GMT
Keywords: Segmentation Violation
Lines: 53

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]>, [e-mail] (Jing Huang) writes:
> [.stuff deleted.]
>|>
>|> segmentation violation in malloc_y at 0xd00d43f0
>|> 0xd00d43f0 (malloc_y+0x2a8) 7c7c45aa       stsi   r3,r28,0x8
>|>
>|>      From these two lines, all I can guess is that the fault is related to
>|> "malloc". But "malloc" is used more than dozens of times throughout the
>|> program, how am I supposed to know "who steps on whose toe and where".
>|>
>
> [.stuff deleted.]
>
>  Usually malloc fails when it can't honor your request for storage.
>i.e. you've requested a huge amount of memory (or even worse, a
>negative amount--which I believe translates into a huge amount as
>well!).
>--


Its even worse than this.  Malloc is not failing,(i.e. returning a NULL)
it is seg faulting!  This is a far more serious problem.  The classic
thing that causes seg faults inside a malloc is overwriting some previously
malloc'ed area.  For example if you malloc an array of size 80 and then
write to array location 81 you've overwritten your malloc'ed space.
This causes serious problems.  Malloc places indexes and pointers in the
space around the area you malloc.  It uses these pointers to help it
keep track of what's malloc'ed and what's not.  If one of these pointers
is trashed it might send malloc on a wild goose chase and cause it to
eventually seg fault.   Unfortunately it is over very difficult to
detect the exact location of these types of errors, especially if
the program is large and does lots of mallocs.

The first thing would be to look at the new code added of course to
see if the error is obvious there.  Then check writing to memory areas
(assigning values to an array, etc.) that occurred not long before the
seg fault happened.  If this fails you need a debugging malloc (a
special malloc that helps to catch these kinds of errors)
Unfortunately IBM provides no such beast but there are ones available
though not readily.  Finally, a program like CodeCenter from
Centerline software is very likely to help but unfortunately costs
$3000/1 user license!  (Every time I say this a CenterLine employee
responds justifying the cost...I guess it is a free market and they
can charge whatever they want)

---------------------------------------------------------------------
David Wojtowicz, meteorological research programmer
Atmospheric Sciences Dept, University of Illinois at Urbana-Champaign
[e-mail], [e-mail]
---------------------------------------------------------------------