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


Robert Schweikert wrote:
> 
> 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?
> 

OK, now I understand what you want.

Note that the level #2 stack entry has all the data because the crt0.o file
that came with your compiler was created with debugging information.

Levels #0 and #1 in the example above use the relocation information that
must exist in the executable file so it can be properly loaded in memory.

Note that a program in your system seems to be loaded at addresses that are
somewhat high:   509cb   486c0    486d3  

In the case you got a core dump  the addresses are much lower:
35a6  bffc  1f69   1eda


Thse may be in a shared-library, so you would have to load the shared
library symbols to be able to see in which functions these addresses are.

Try "info shared" and see if you can figure where these addresses belong.

Good luck.

Fernando



> 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

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

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