This is the mail archive of the gdb-patches@sourceware.org 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]

[commit/Ada] GDB crash printing tagged type variable


One of my coworkers reported that the debugger crashes when trying
to print his local variable "X" in the following program:

    with Ada.Strings.Unbounded;
    procedure Main is
       X : Ada.Strings.Unbounded.Unbounded_String;
    begin
       null;
    end Main;

The problem was that GDB was attempting to determine the real type
of our variable by using its tag (this is the data that allows us
to tell the real type of our variable).  The algorithm is slightly
complex but needs to have type Ada.Tags.Type_Specific_Data defined in
the debugging info. This is the case as soon as one unit defining
a tagged type is compiled with debugging info [1].

The reason for inspecting the tag is to handle cases where the
actual type for our variable is dynamic. Consider for instance:

    X : Object'Class := New_Object;

In that case, the debugging information says that variable X is
an obscure unnamed structure whose fields are "_parent" and "C9b".
If we followed this definition blindly, we would get:

    (gdb) p x
    $2 = (x => 0, y => 0, C9b => ())

So, in our case, the debug info was missing, and GDB wasn't prepared
to handle that. This is what this patch does: If we don't find
sufficient debugging information, then use the static information
that we have.  In the case reported by my coworker, this is going
to be sufficient, because the variable type is statically known.

Unfortunately, this is not sufficient in the case where the type
is NOT statically known. We tried to come up with a number of
strategies to be able to retrieve the type name without using
the debugging info, but we eventually concluded that this was
a lost cause, and gave up.

We think that, in practice, the majority of users who use tagged
types will define at least one tagged type in their application,
and that'll be enough to avoid the issue. In the meantime, we do
our best, and no longer crash.

2009-03-12  Joel Brobecker  <brobecker@adacore.com>

        * ada-lang.c (ada_evaluate_subexp) [OP_VAR_VALUE]: For tagged
        types, if we are unable to determine the actual symbol type
        from its tag, then use the static approximation instead.

Tested on amd64-linux. Checked in.

-- 
Joel

[1]: This is because the expanded code associated to the definition
     of a tagged type contains a reference to that Type_Specific_Data
     type, and thus causes it to be included in the debugging info for
     that unit.

commit 9116f9327d3c7bd8abd68f2bf7f79ffb6d5e4108
Author: Joel Brobecker <brobecker@adacore.com>
Date:   Thu Mar 12 14:36:32 2009 -0700

    gdb internal error on print value of unbounded string
    
                * ada-lang.c (ada_evaluate_subexp) [OP_VAR_VALUE]: For tagged
                types, if we are unable to determine the actual symbol type
                from its tag, then use the static approximation instead.
                Prevents an internal error reported under HC23-003.

diff --git a/gdb/ada-lang.c b/gdb/ada-lang.c
index 6988594..0724804 100644
--- a/gdb/ada-lang.c
+++ b/gdb/ada-lang.c
@@ -8576,8 +8576,19 @@ ada_evaluate_subexp (struct type *expect_type, struct expression *exp,
                a fixed type would result in the loss of that type name,
                thus preventing us from printing the name of the ancestor
                type in the type description.  */
+            struct type *actual_type;
+
             arg1 = evaluate_subexp (NULL_TYPE, exp, pos, EVAL_NORMAL);
-            return value_zero (type_from_tag (ada_value_tag (arg1)), not_lval);
+            actual_type = type_from_tag (ada_value_tag (arg1));
+            if (actual_type == NULL)
+              /* If, for some reason, we were unable to determine
+                 the actual type from the tag, then use the static
+                 approximation that we just computed as a fallback.
+                 This can happen if the debugging information is
+                 incomplete, for instance.  */
+              actual_type = type;
+
+            return value_zero (actual_type, not_lval);
           }
 
           *pos += 4;

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