This is the mail archive of the 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]
Other format: [Raw text]

[stabs/commit] fix another TYPE_INSTANCE_FLAGS failed assertion

We started spotting many of these failed assertion a few days ago:

    gdbtypes.c:640: internal-error: replace_type: Assertion `TYPE_INSTANCE_FLAGS (ntype) == TYPE_INSTANCE_FLAGS (type)' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.

It's related to forward references to types that are defined as a constant
or volatile variation of another type. For instance:

    .stabx  "uw_exception:p265",120,130,0
    .stabx  "ada__exceptions__exception_propagation__T216bXn:t265=k264",0,140,0

The compiler actually generated these stabs in the right order, so the
variable was defined after the type. But the AIX linker seems to have
played with the stabs and moved them around, causing this misordering.

However, the misordering shouldn't be a problem for the debugger who's
been taught how to deal with them: We have a vector of undefined types
that we then go through after having read all stabs from the unit, and
replace all undefined types by their actual definition.

The problem in this case is that the instance flags of the undefined
type was still unset, and so we tripped an assertion inside replace_type
that expects the instance flags of both the source and target types
to be identical. The fix was to set this flag manually before calling

2008-04-08  Joel Brobecker  <>

        * stabsread.c (cleanup_undefined_types_noname): Manually set the
        instance flags of the undefined type before calling replace_type.

Tested on ppc-aix and x86-linux (using -gstabs+).
Checked in.


Attachment: undef.diff
Description: Text document

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