This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: gdb/1170: gdb-5.3 just doesn't work on aix5.1
- From: David Edelsohn <dje at watson dot ibm dot com>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 2 Apr 2003 20:48:01 -0000
- Subject: Re: gdb/1170: gdb-5.3 just doesn't work on aix5.1
- Reply-to: David Edelsohn <dje at watson dot ibm dot com>
The following reply was made to PR gdb/1170; it has been noted by GNATS.
From: David Edelsohn <dje at watson dot ibm dot com>
To: rutt at chezrutt dot com
Cc: gdb-gnats at sources dot redhat dot com
Subject: Re: gdb/1170: gdb-5.3 just doesn't work on aix5.1
Date: Wed, 02 Apr 2003 15:44:24 -0500
Saying "gdb-5.3 just doesn't work on aix5.1" was hyperbole and
incorrect. This should have been reported as a problem debugging G++
code, not AIX-specific. This likely is not AIX-specific.
David
>>>>> John Ruttenberg writes:
John> I did some debugging on this and I can supply some more information about what
John> is wrong.
John> Gdb is indeed crashing with an internal error. Our application is written in
John> C++ and does use pthreads. I think the problem is caused by the fact that our
John> application makes heavy use of templates and STL in particular. I don't think
John> pthreads has anything to do with it since the application doesn't have to
John> actually run in order to reproduce. I can caues the gdb internal error just
John> by setting a break point before running the application.
John> The assertion at line 514 of gdbtypes.h is failing. At this point,
John> make_cv_type has been called from line 2709 of stabsread.c. I think the
John> problem is that read_type has just returned builtin_type_error which doesn't
John> have a objfile and is not a stub. dbx_lookup_type did manage to find
John> something that has the correct name of the objfile set. Hence the assertion
John> failure.
John> The string that is passed to read_type that causes it to return
John> builtin_type_error is:
John> 0x2022529f ",3310=&3311=k778,-11;:_ZNSt4pairIPKcPiEC2ERKS1_RKS2_;2A.;__comp_ctor::3307:_ZNSt4pairIPKcPiEC1ERKS1_RKS2_;2A.;;"
John> which c++filt turns into:
John> 0x2022529f ",3310=&3311=k778,-11;:std::pair<char const*, int*>::pair[not-in-charge](char const* const&, int* const&);2A.;__comp_ctor::3307:std::pair<char const*, int*>::pair[in-charge](char const* const&, int* const&);2A.;;"
John> The template usage in this string is what makes me think that this has
John> something to do with templates. I tried to reproduce in a smaller program,
John> but so far I haven't been successful.
John> I have worked around the problem (for now) by removing the assertion. Now dbx
John> no longer crashes, but clearly it cannot handle some C++ types and something
John> is bound to be broken.
John> I don't know how to add this note to the bug entry. If you aren't going to
John> work on the bug, please add so that the person who actually does will have the
John> info. In that case, perhaps you should alert the correct person(s).
John> Thanks.
John> David Edelsohn:
>> Can you be a little more specific about the type of application
>> you are trying to debug? I assume from the gdb stack backtrace that gdb
>> itself is crashing with an internal error? Is your application written in
>> C or C++? Does your application use pthreads? Does your application use
>> shared libraries or shared objects (DLLs) created by the application? Are
>> you linking the application staticly?
>>
>> I just built gdb-5.3 on AIX 5.1 using gcc-3.2.2. In my
>> preliminary tests debugging GCC cc1, things worked fine and gdb did not
>> crash.
>>
>> David
John> [rutt at aix2 intcache]$ c++filt
John> 0x2022529f ",3310=&3311=k778,-11;:_ZNSt4pairIPKcPiEC2ERKS1_RKS2_;2A.;__comp_ctor::330\
John> 7:_ZNSt4pairIPKcPiEC1ERKS1_RKS2_;2A.;;"
John> 0x2022529f ",3310=&3311=k778,-11;:std::pair<char const*, int*>::pair[not-in-charge](c\
John> har const* const&, int* const&);2A.;__comp_ctor::3307:std::pair<char const*, int*>::p\
John> air[in-charge](char const* const&, int* const&);2A.;;"