Very Computer

Hello Linux-People,

I have the funny effect that some programs written by me are
terminated by a SIGSEGV. When running them in gdb 4.16 it shows up
that the segfaults appear at the very end of a function, i.e., in the
line that contains the closing "}". It is interesting that gdb also
gets sometimes mixed up with the function names. For example, it
outputs a segfault in somefunction() in test.c line 232: ->  } but
somefunction() is located at a position far away from line 232 in
test.c.

This behaviour appeared first and mostly (but not exclusively) when I
tried to debug my program with the Electric Fence library in order to
check for malloc-errors.

I have gcc 2.7.2, gdb 4.16 (binary from slackware) and libc
5.4.33. I'm afraid I have some incompatible versions of system
software in my setup. Because my old gprof did not run anymore I
recently updated to binutils 2.8.1.

Has someone made similar experiences or an idea how to fix this?

Thanks for your answers,
                    Rainer

--

*** ____ ****** . * . ******* Dipl.-Ing. Rainer Menzner ********************
   ( /  \      /|  /|         Ruhr-Universitaet Bochum  
    /    |    / | / |         Institut fuer Neuroinformatik
   /____/    /  |/  |  __     D-44780 Bochum, Germany
  / \       /   '   | ( /     ----------------------------------------------
(/   \_ o (/        | -/- o  
********************* /--) ** Tel. +49-234/700-7978 ************************

WWW:   http://www.neuroinformatik.ruhr-uni-bochum.de/ini/PEOPLE/rmz/top.html

: Hello Linux-People,

: I have the funny effect that some programs written by me are
: terminated by a SIGSEGV. When running them in gdb 4.16 it shows up
: that the segfaults appear at the very end of a function, i.e., in the
: line that contains the closing "}". It is interesting that gdb also

This is indicative of the stack having been trashed somewhere in the
function that is returning. When a function is called, as part
of the setup for the call, but before the call is done the address of
the next instruction (following the call) in the calling function is
pushed onto the stack. When the called function returns this address
is retrieved and is used as the next instruction to execute. When
some bit of code overwrites the stack one of the things there to be
damaged is this return address. When a returning function goes off
into the weeds as you describe its almost 100% certain that it (or
some function IT has called) has stepped on its own return address.

: gets sometimes mixed up with the function names. For example, it
: outputs a segfault in somefunction() in test.c line 232: ->  } but
: somefunction() is located at a position far away from line 232 in
: test.c.

could also be due to stack corruption.

You've got a bug in your program somewhere and need to track it
down. These kinds of things can be painful and tedious to locate.

Fred
--

                       I can do all things through Christ
                              who strengthens me.
------------------------------ Philippians 4:13 -------------------------------