Re: traceback troubles

[Fernando Nasser <fnasser@cygnus.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4318 bytes --]

Robert Schweikert wrote:
> 
> Is there a way to figure out where things went wrong with this type of
> traceback?
> 
> Program terminated with signal 11, Segmentation fault.
> #0  0x400035a6 in ?? ()
> (gdb) where
> #0  0x400035a6 in ?? ()
> #1  0x4000bffc in ?? ()
> #2  0x40001f69 in ?? ()
> #3  0x40001eda in ?? ()
> 
> This is version 4.18 of gdb.
> 
> The code was compiled with gcc 2.95.2 on RedHat 6.1 without the -g
> option. However, shouldn't I still get a stacktrace that at least points
> me to the routine where things went wrong. This is C++ code.
> 
> Any help is appreciated.
> 

Robert,

The debug information contains, among many other things, where the
functions start.  If you have no debug information passed to the debugger
it cannot guess where these addresses belong.

Bottom line: if you want symbolic debugging, use "-g".


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
From chastain@cygnus.com Sat Dec 09 09:47:00 2000
From: Michael Elizabeth Chastain <chastain@cygnus.com>
To: cadamuro@lit.cpdtt.cefetpr.br
Cc: gdb@sources.redhat.com
Subject: Re: GDB for powerpc-eabi under cygwin,
Date: Sat, 09 Dec 2000 09:47:00 -0000
Message-id: <200012091750.JAA30627@train2.cygnus.com>
X-SW-Source: 2000-12/msg00055.html
Content-length: 379

Hello João,

> 1. PowerPC simulator don't work for snapshot 2000-08-16.
> 
> If you compile a simple "Hello Word" for the simulator and try to debug
> it with GDB, you'll be "ejected"...

I finished testing Jim Blandy's patch for this problem.  It worked fine
and I have committed it to sourceware.

Michael Elizabeth Chastain
< mailto:chastain@redhat.com >
"love without fear"
From rjschwei@mindspring.com Sat Dec 09 10:24:00 2000
From: Robert Schweikert <rjschwei@mindspring.com>
To: Fernando Nasser <fnasser@cygnus.com>
Cc: gdb@sources.redhat.com
Subject: Re: traceback troubles
Date: Sat, 09 Dec 2000 10:24:00 -0000
Message-id: <3A32783C.65092D5B@mindspring.com>
References: <3A321CD2.98CBC116@mindspring.com> <3A324945.8A78CD9@cygnus.com>
X-SW-Source: 2000-12/msg00056.html
Content-length: 2157

Fernando,

Thanks, however my simple example below allows me to get the info I want
without the -g compiler flag.

void dumpCore()
{
  char* null = 0;

  *null = 'a';
}

void main (void)
{
  dumpCore();

}

->g++ dump.C
-> ./a.out
Segmentation fault (core dumped)
->gdb a.out core
#0  0x80486c0 in dumpCore ()
(gdb) where
#0  0x80486c0 in dumpCore ()
#1  0x80486d3 in main ()
#2  0x400509cb in __libc_start_main (main=0x80486c8 <main>, argc=1,
    argv=0xbffff554, init=0x80484d4 <_init>, fini=0x804a194 <_fini>,
    rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffff54c)
    at ../sysdeps/generic/libc-start.c:92

That's all the info I am after, the other stuff is a large application and
globally compiling with debug mode will swell the code tremendously, plus it
means a 6-7 hour recompile of all the code, since I don't know right now
where things are blowing up.

Is there anyway to figure out what's going on from the addresses?

Thanks,
Robert

Fernando Nasser wrote:

> Robert Schweikert wrote:
> >
> > Is there a way to figure out where things went wrong with this type of
> > traceback?
> >
> > Program terminated with signal 11, Segmentation fault.
> > #0  0x400035a6 in ?? ()
> > (gdb) where
> > #0  0x400035a6 in ?? ()
> > #1  0x4000bffc in ?? ()
> > #2  0x40001f69 in ?? ()
> > #3  0x40001eda in ?? ()
> >
> > This is version 4.18 of gdb.
> >
> > The code was compiled with gcc 2.95.2 on RedHat 6.1 without the -g
> > option. However, shouldn't I still get a stacktrace that at least points
> > me to the routine where things went wrong. This is C++ code.
> >
> > Any help is appreciated.
> >
>
> Robert,
>
> The debug information contains, among many other things, where the
> functions start.  If you have no debug information passed to the debugger
> it cannot guess where these addresses belong.
>
> Bottom line: if you want symbolic debugging, use "-g".
>
> --
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9

--
Robert Schweikert                      MAY THE SOURCE BE WITH YOU
rjschwei@mindspring.com                         LINUX