This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
gdb crashes due to a gcc bug (on AIX)
- From: "Michael Veksler" <VEKSLER at il dot ibm dot com>
- To: gdb at sources dot redhat dot com
- Date: Thu, 28 Aug 2003 09:59:35 +0300
- Subject: gdb crashes due to a gcc bug (on AIX)
- Sensitivity:
gcc-3.2.1 emits wrong stubs debug information. This causes an assertion
failure in gdb on AIX. This failure happens during "break main".
The version that crashes is a weekly snapshot:
GNU gdb 20030729
The unsorted debug information (nm -Cpf) is as follows:
_ZNKSt5ctypeIcE5tableEv:f1934=*1785 - 6648
This is the first occurrence of symbol 1785, and here we see the bug.
There is a "=k-8" missing. When according to rs6000_builtin_type,
"-8" stands for "unsigned int".
The line should have been:
_ZNKSt5ctypeIcE5tableEv:f1934=*1785=k-8 - 6648
This does not cause the crash yet. After several simple and harmless
references to 1785, there is:
locale:Tt1784=s4none:/21785=k-8:_ZNSt6locale4noneE;ctype:/21785:_ZNSt6
......
This line should have been the first reference to 1785 because it defines
it to be k-8 (unsigned int). When GDB gets to this part of the debug info
it crashes. Here is the analysis of the crash:
stabsread.c:read_type(.....):
Reads 1785 and gets previously read debug information into
typeptr. This debug info is wrong, because it is not marked as
a builtin type (due to original missing "=k-8")
Enters the case for 'k' with typeptr wrongly marked as defined in
this translation unit: TYPE_OBJFILE(*typeptr)->name != NULL
and wrongly read a new type for -8 into 'type' for which:
TYPE_OBJFILE(*typeptr)->name == NULL
make_cv_type is called with a bad typeptr and type combination
that crashes in its gdb_assert call.
I know that this is a gcc bug, but I also think that gdb should not crash
on such gcc bugs. This happens for gcc-3.2, for which development
had stopped, so it is not reasonable to look for a fix there.
It is difficult to generate this gcc bug on purpose (using a simple
example), although it happens all the time by accident :-(
I'll report this bug to GCC team once a simple example is found...
Also note that there is a PR for this bug that lacks this analysis. It is
GDB PR 1170.