Debuging Segmentation Violation Fault

Debuging Segmentation Violation Fault

Post by Jing Hua » Sat, 15 Aug 1992 13:00:21



        Dear netters, I have always wanted to ask this question. To me, the
most horrifying error a program can have is "segmentation violation". I never
have any clear idea about how to debug this kind of fault. Can someone give
me some advice from his own experience on how to solve this fault?

        I have this HUGE C program (20,000 lines). Everything worked fine
until the other day I added a few (about 10) lines to it. Then all of a sudden,
it keeps giving me this "segmentation violation". I ran "dbx" to see if I can
get some clue, it gave me something like:

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".

        I am desperate. Could someone tell me what other things I should do
beyond these two lines? Or maybe what books or manuals should I read to get
more information? What do those address-like (?) numbers all mean?

        Many thanks in advance.

--

Department of Physics
Kent State University
Kent, OH 44242

 
 
 

Debuging Segmentation Violation Fault

Post by Lance Pick » Sat, 15 Aug 1992 21:16:19


|>      Dear netters, I have always wanted to ask this question. To me, the
|> most horrifying error a program can have is "segmentation violation". I never
|> have any clear idea about how to debug this kind of fault. Can someone give
|> me some advice from his own experience on how to solve this fault?
|>
|>      I have this HUGE C program (20,000 lines). Everything worked fine
|> until the other day I added a few (about 10) lines to it. Then all of a sudden,
|> it keeps giving me this "segmentation violation". I ran "dbx" to see if I can
|> get some clue, it gave me something like:
|>
|> 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".
|>
|>      I am desperate. Could someone tell me what other things I should do
|> beyond these two lines? Or maybe what books or manuals should I read to get
|> more information? What do those address-like (?) numbers all mean?
...

Jing,

  The next step inside dbx would be to use the t command to get a
list of the traceback stack.  The line you see above will be at the
top, the function which called it will be on the next line, and so
on.  You will eventually see your functions in the traceback,
and if you compiled with -g you can even see line numbers and
parameters passed.  This should point you to the line in your code
which is calling malloc which fails.

  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!).
--
    ...Lance

-----------------------------------------------------------------------


Technology Products
Burlington, VT                          Phone: (802) 769-7104 (tie 446)
-----------------------------------------------------------------------

 
 
 

Debuging Segmentation Violation Fault

Post by David Wojtowi » Sun, 16 Aug 1992 00:21:30




> [.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

---------------------------------------------------------------------

 
 
 

Debuging Segmentation Violation Fault

Post by Bjorn Engs » Tue, 18 Aug 1992 19:24:37



|it keeps giving me this "segmentation violation". I ran "dbx" to see if I can
|get some clue, it gave me something like:
|
|segmentation violation in malloc_y at 0xd00d43f0
|0xd00d43f0 (malloc_y+0x2a8) 7c7c45aa       stsi   r3,r28,0x8
In 99% of the cases when you get segmentation violation (or bus error) in
malloc, it's because you previously malloc'ed less than you actually used.
In some systems (including AIX 3.1), this was not always harmful, as malloc
often gave you (much) more than you asked for.  In other systems (including
AIX 3.2), malloc only gives you very little more than you asked for.  If you
are on 3.2, try running your program with the MALLOCTYPE=3.1 environment--
if that makes your problem disappear, then you surely ask for less than
you use.

BTW, 78.5% of all statistics are made up.
|
|       I am desperate. Could someone tell me what other things I should do
|beyond these two lines? Or maybe what books or manuals should I read to get
|more information?
It will most likely be very beneficial for you to learn how to use the
de* (dbx).
--

ORACLE Corporation.     BANG-net: uunet!oracle!bengsig

 
 
 

Debuging Segmentation Violation Fault

Post by Chan Bens » Thu, 20 Aug 1992 06:47:19


Quote:> |>      I have this HUGE C program (20,000 lines). Everything worked fine
> |> until the other day I added a few (about 10) lines to it. Then all of a sudden,
> |> it keeps giving me this "segmentation violation". I ran "dbx" to see if I can
> |> get some clue, it gave me something like:
> |>
> |> 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".
> |>
> |>      I am desperate. Could someone tell me what other things I should do
> |> beyond these two lines? Or maybe what books or manuals should I read to get
> |> more information? What do those address-like (?) numbers all mean?
> ...

>   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!).

Nice try, but if malloc is giving a segmentation violation that usually
means that the program wrote beyond the boundary of a previously malloc'ed
area (thus trashing malloc's allocation info). These bugs are difficult
to find without a debug version of the malloc library.

                        -- Chan Benson
                        HP Fort Collins

 
 
 

Debuging Segmentation Violation Fault

Post by Kevin Smi » Tue, 06 Oct 1992 23:29:49



:>
:>   Dear netters, I have always wanted to ask this question. To me, the
:>most horrifying error a program can have is "segmentation violation". I never
:>have any clear idea about how to debug this kind of fault. Can someone give
:>me some advice from his own experience on how to solve this fault?
:>
:>   I have this HUGE C program (20,000 lines). Everything worked fine
:>until the other day I added a few (about 10) lines to it. Then all of a sudden,
:>it keeps giving me this "segmentation violation". I ran "dbx" to see if I can
:>get some clue, it gave me something like:
:>
:>segmentation violation in malloc_y at 0xd00d43f0
:>0xd00d43f0 (malloc_y+0x2a8) 7c7c45aa       stsi   r3,r28,0x8

As other people have responded, this is most likely a problem with someone
overrunning their malloc'ed buffer and corrupting malloc's pointers.  These
types of problems are notoriously difficult to debug.  A usefull technique
is to determine how much memory is being requested in the malloc() that
fails then to sprinkle equivalent malloc()'s in the code at stratigic
locations.  You should be able to brackett the code causing the corruption
and iterate your way down to the line causing the corruption.
--
            | Email - !shady!kevin uunet!shady!kevin
Kevin Smith | Voice - (908) 874-7980
            | Mail  - ShadeTree Software, Inc., 192 Capricorn Dr. #10,
            |         Somerville, NJ  08876

 
 
 

Debuging Segmentation Violation Fault

Post by Conor P. Cahi » Wed, 07 Oct 1992 19:47:42



> As other people have responded, this is most likely a problem with someone
> overrunning their malloc'ed buffer and corrupting malloc's pointers.  These
> types of problems are notoriously difficult to debug.  A usefull technique

Our product, SENTINEL, is designed to make this kind of problem resolution
easy (so easy, in fact, that SENTINEL usually finds the problems before you
are aware that they are there).  

We are in the process of porting the product to the RS6000 and it should be
ready in approx 3 weeks.

Email if you would like additional informatin.

Conor

--
*** SENTINEL(tm) The ultimate Debugging Environment - email for more info ***


Virtual Technologies, Inc.  46030 Manekin Plaza          Dulles, VA 20166

 
 
 

Debuging Segmentation Violation Fault

Post by Tony Ro » Thu, 08 Oct 1992 19:50:01




>:>
>:>       I have this HUGE C program (20,000 lines). Everything worked fine
>:>until the other day I added a few (about 10) lines to it. Then all of a sudden,
>:>it keeps giving me this "segmentation violation". I ran "dbx" to see if I can
>:>get some clue, it gave me something like:
>:>
>:>segmentation violation in malloc_y at 0xd00d43f0
>:>0xd00d43f0 (malloc_y+0x2a8) 7c7c45aa       stsi   r3,r28,0x8

We recently obtained a library of routines called malloclib from the Free
Software Foundation.  This produces detailed reports of malloc problems.  Try
getting this library and compiling your code against it.

Tony

 
 
 

1. Follow-up: Re: Debuging Segmentation Violation Fault

        My wholehearted thanks to all of those who responded to my question.
Almost without an exception, I was advised to issue the "where" command to
get a trace-back of all the subroutines that uses the "malloc".

        However, to my great surprise, it later turned out that nothing was
wrong with my program. It was the system's library which got corrupted. And
I did not find this out until someone else took my favorite seat and I was
forced to use another computer (we have 9 AIX). I would have never suspected
the system itself and could have spent my whole life (?) in vain.

        Keep in mind folks, next time you hit some strange behavior, try it
out on another computer first.

        Again, thanks a lot.

--

Department of Physics
Kent State University
Kent, OH 44242

2. Using INN server

3. Compiling *** VIM 5.3 *** Segmentation Fault..what is Seg-Fault..MEM Bounds?

4. upgrade to redhat 7.0 beta ?

5. Page Faults/Segmentation Faults??

6. Lilo quits upom reading Adaptec 2842a controller

7. INIT: PANIC: segmentation violation! giving up..

8. Teledat ISDN/USB Fritztype thingy

9. segmentation violation in ncurses

10. PANIC: INIT: segmentation violation ...

11. segmentation violation

12. JDK 1.1.1 - segmentation violation

13. lpsfilt - Segmentation Violation