This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: traceback troubles
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