This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]