traceback troubles

traceback troubles

[Robert Schweikert]

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.

Thanks,
Robert



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

Re: traceback troubles

[Fernando Nasser]

[-- 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

Re: traceback troubles

[Fernando Nasser]

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
From kevinb@cygnus.com Sat Dec 09 15:05:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: gjertsen@us.ibm.com
Cc: bug-gdb@gnu.org, gdb@sources.redhat.com
Subject: Re: gdb 5.0 "ia64-unknown-linux" segv error
Date: Sat, 09 Dec 2000 15:05:00 -0000
Message-id: <1001209230540.ZM25815@ocotillo.lan>
References: <852569AF.0071239B.00@d54mta01.raleigh.ibm.com>
X-SW-Source: 2000-12/msg00058.html
Content-length: 1337

On Dec 8,  3:34pm, gjertsen@us.ibm.com wrote:

> I've transferred the ~24Mb file, testcase.tar.gz, over to the incoming
> location.
> 
> The name/size information is:
> 
> -rw-rw-r--   1 gjertsen gjertsen 24473202 Dec  8 15:33 testcase.tar.gz
> 
> tar file contents:
> -rwxrwxr-x   1 gjertsen gjertsen 74072196 Dec  8 15:30 mmfsd
> -rw-rw-r--   1 gjertsen gjertsen  3158277 Dec  8 15:30 mmfsd.map

Thanks for the test case.  I am able to reproduce the bug that you
reported.  I've done some investigation and I now wonder what tools
you used to create mmfsd.  (I.e, I wonder if the bug is actually in
the compiler.)  I've used "readelf -wi" to look at the debugging
symbols in mmfsd and I see the following:

 <1><96d50>: Abbrev Number: 12 (DW_TAG_typedef)
     DW_AT_name        : ulong  
     DW_AT_decl_file   : 12     
     DW_AT_decl_line   : 59     
     DW_AT_type        : <96d50>        

I'm not a DWARF2 expert, but it looks to me like the above is a
self referential typedef.  This would explain why you're seeing
the infinite recursion in dwarf2read.c.

I've cc'd the gdb discussion list so that others more expert than
myself regarding DWARF2 can weigh in on this problem.  For those
of you who missed the original bug report, it may be found at:

    http://mail.gnu.org/pipermail/bug-gdb/2000-December/001542.html

Kevin
From davea@quasar.engr.sgi.com Sat Dec 09 15:33:00 2000
From: David B Anderson <davea@quasar.engr.sgi.com>
To: gjertsen@us.ibm.com, Kevin Buettner <kevinb@cygnus.com>
Cc: gdb@sources.redhat.com, bug-gdb@gnu.org
Subject: Re: gdb 5.0 "ia64-unknown-linux" segv error
Date: Sat, 09 Dec 2000 15:33:00 -0000
Message-id: <200012092333.PAA25693@quasar.engr.sgi.com>
References: <852569AF.0071239B.00@d54mta01.raleigh.ibm.com>
X-SW-Source: 2000-12/msg00059.html
Content-length: 1123

kevinb writes:
> <1><96d50>: Abbrev Number: 12 (DW_TAG_typedef)
>     DW_AT_name        : ulong  
>     DW_AT_decl_file   : 12     
>     DW_AT_decl_line   : 59     
>     DW_AT_type        : <96d50>        
>
>I'm not a DWARF2 expert, but it looks to me like the above is a
>self referential typedef.  This would explain why you're seeing
>the infinite recursion in dwarf2read.c.

Yes, it is a bug. This is not correct dwarf2.

I was going to say it was 'illegal' dwarf2, but the spec
does not quite allow me to say that:
the spec:

.H 2 "Typedef Entries"
.IX typedefs
Any arbitrary type named via a typedef is represented
by a debugging information entry with the tag
.Cf DW_TAG_typedef .
The typedef entry has a
.Cf DW_AT_name
attribute whose value is a null-terminated
string containing the name of the typedef as it appears in the
source program.
The typedef entry also contains a
.Cf DW_AT_type
attribute.

The above is the same in the latest draft dwarf2 spec.

It is clear from context though, that the DW_AT_type
should be a reference to 'the type the ulong name refers to'
in the example at hand.


davea@sgi.com
From davea@quasar.engr.sgi.com Sat Dec 09 15:49:00 2000
From: David B Anderson <davea@quasar.engr.sgi.com>
To: Kevin Buettner <kevinb@cygnus.com>, gjertsen@us.ibm.com, David B Anderson <davea@quasar.engr.sgi.com>
Cc: bug-gdb@gnu.org, gdb@sources.redhat.com
Subject: Re: gdb 5.0 "ia64-unknown-linux" segv error
Date: Sat, 09 Dec 2000 15:49:00 -0000
Message-id: <200012092348.PAA99642@quasar.engr.sgi.com>
References: <852569AF.0071239B.00@d54mta01.raleigh.ibm.com>
X-SW-Source: 2000-12/msg00060.html
Content-length: 945

>kevinb writes:
>> <1><96d50>: Abbrev Number: 12 (DW_TAG_typedef)
>>     DW_AT_name        : ulong  
>>     DW_AT_decl_file   : 12     
>>     DW_AT_decl_line   : 59     
>>     DW_AT_type        : <96d50>        
>>
>>I'm not a DWARF2 expert, but it looks to me like the above is a
>>self referential typedef.  This would explain why you're seeing
>>the infinite recursion in dwarf2read.c.
>
>Yes, it is a bug. This is not correct dwarf2.
>
>I was going to say it was 'illegal' dwarf2, but the spec
>does not quite allow me to say that:
>the spec:

No, I was wrong, it is illegal dwarf2.

Section 2.5  of the July 1993 spec (v2.0.0)
and section 2.6 of the current draft  version both have:

  Any debugging information entry describing a declaration that
  has a type has a DW_AT_type attribute, whose value is a
  reference to another debugging information entry.

which is clear enough, and rules out the dwarf2 example above.

davea@sgi.com
From kuhlen@gmx.net Sat Dec 09 16:46:00 2000
From: "Bernd K." <kuhlen@gmx.net>
To: gdb@sourceware.cygnus.com
Subject: problems with gdb
Date: Sat, 09 Dec 2000 16:46:00 -0000
Message-id: <3A32D242.4010002@gmx.net>
X-SW-Source: 2000-12/msg00061.html
Content-length: 171

Hi,
i can't debug my programs. If i write "gdb program" and then for 
instance "list" it returns
"init.c no such file or directory".
What's wrong?

Regards,
Bernd Kuhlen