[Bug ada/25837] New: [cc-with-debug-names] gdb.ada/big_packed_array segv

[Bug ada/25837] New: [cc-with-debug-names] gdb.ada/big_packed_array segv

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25837

            Bug ID: 25837
           Summary: [cc-with-debug-names] gdb.ada/big_packed_array segv
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ada
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

When running test-case gdb.ada/big_packed_array with target board
cc-with-debug-names, I get:
...
(gdb) print bad^M
warning: could not find bounds information on packed array^M
ERROR: GDB process no longer exists
GDB process exited with wait status 28797 exp9 0 0 CHILDKILLED SIGABRT SIGABRT
UNRESOLVED: gdb.ada/big_packed_array.exp: print bad
...

Easy to reproduce like this:
...
$ gdb -batch outputs/gdb.ada/big_packed_array/foo_ra24_010 -ex "start" -ex
"print bad"
...

segv here:
...
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
0x000000000042e41e in to_fixed_array_type (type0=0x0, dval=0x0,
ignore_too_big=1)
    at /data/gdb_versions/devel/src/gdb/ada-lang.c:8704
8704          struct type *elt_type0 = ada_check_typedef (TYPE_TARGET_TYPE 
(type0));
...


Backtrace at segv:
...
(gdb) bt
#0  0x000000000042e41e in to_fixed_array_type (type0=0x0, dval=0x0,
ignore_too_big=1)
    at /data/gdb_versions/devel/src/gdb/ada-lang.c:8704
#1  0x000000000042e95d in ada_to_fixed_type_1 (type=0x1ae49e0, valaddr=0x0,
address=140737488345552, dval=0x0, 
    check_tag=1) at /data/gdb_versions/devel/src/gdb/ada-lang.c:8906
#2  0x000000000042ea2c in ada_to_fixed_type (type=0x1ae49e0, valaddr=0x0,
address=140737488345552, dval=0x0, 
    check_tag=1) at /data/gdb_versions/devel/src/gdb/ada-lang.c:8941
#3  0x000000000042ed0b in ada_to_fixed_value_create (type0=0x1ae49e0,
address=140737488345552, val0=0x1c6f8b0)
    at /data/gdb_versions/devel/src/gdb/ada-lang.c:9090
#4  0x000000000042edc2 in ada_to_fixed_value (val=0x1c6f8b0) at
/data/gdb_versions/devel/src/gdb/ada-lang.c:9114
#5  0x00000000004322ec in ada_evaluate_subexp (expect_type=0x0, exp=0x1b7bb60,
pos=0x7fffffffd1c4, 
    noside=EVAL_AVOID_SIDE_EFFECTS) at
/data/gdb_versions/devel/src/gdb/ada-lang.c:10677
#6  0x0000000000620d68 in evaluate_subexp (expect_type=0x0, exp=0x1b7bb60,
pos=0x7fffffffd1c4, 
    noside=EVAL_AVOID_SIDE_EFFECTS) at
/data/gdb_versions/devel/src/gdb/eval.c:77
#7  0x000000000042f72f in evaluate_subexp_type (exp=0x1b7bb60,
pos=0x7fffffffd1c4)
    at /data/gdb_versions/devel/src/gdb/ada-lang.c:9437
#8  0x0000000000423e48 in resolve_subexp (expp=0x7fffffffd418,
pos=0x7fffffffd1c4, deprocedure_p=1, 
    context_type=0x0, parse_completion=0, tracker=0x7fffffffd2f0)
    at /data/gdb_versions/devel/src/gdb/ada-lang.c:3846
#9  0x0000000000422f9a in resolve (expp=0x7fffffffd418, void_context_p=0,
parse_completion=0, 
    tracker=0x7fffffffd2f0) at /data/gdb_versions/devel/src/gdb/ada-lang.c:3483
#10 0x00000000007af75e in parse_exp_in_context (stringptr=0x7fffffffd3d0, pc=0,
block=0x0, comma=0, 
    void_context_p=0, out_subexp=0x0, tracker=0x7fffffffd2f0, cstate=0x0)
    at /data/gdb_versions/devel/src/gdb/parse.c:1149
#11 0x00000000007af41a in parse_exp_1 (stringptr=0x7fffffffd3d0, pc=0,
block=0x0, comma=0, tracker=0x0)
    at /data/gdb_versions/devel/src/gdb/parse.c:1031
--Type <RET> for more, q to quit, c to continue without paging--
#12 0x00000000007af8c1 in parse_expression (string=0x7fffffffe0eb "bad",
tracker=0x0)
    at /data/gdb_versions/devel/src/gdb/parse.c:1167
#13 0x00000000007b2ba8 in print_command_1 (args=0x7fffffffe0eb "bad",
voidprint=1)
    at /data/gdb_versions/devel/src/gdb/printcmd.c:1214
#14 0x00000000007b2d1e in print_command (exp=0x7fffffffe0eb "bad", from_tty=0)
    at /data/gdb_versions/devel/src/gdb/printcmd.c:1244
#15 0x00000000004fd6be in do_const_cfunc (c=0x198b910, args=0x7fffffffe0eb
"bad", from_tty=0)
    at /data/gdb_versions/devel/src/gdb/cli/cli-decode.c:107
#16 0x0000000000500676 in cmd_func (cmd=0x198b910, args=0x7fffffffe0eb "bad",
from_tty=0)
    at /data/gdb_versions/devel/src/gdb/cli/cli-decode.c:1952
#17 0x000000000090ab33 in execute_command (p=0x7fffffffe0ed "d", from_tty=0)
    at /data/gdb_versions/devel/src/gdb/top.c:655
#18 0x0000000000738bcd in catch_command_errors (command=0x90a6c7
<execute_command(char const*, int)>, 
    arg=0x7fffffffe0e5 "print bad", from_tty=0) at
/data/gdb_versions/devel/src/gdb/main.c:457
#19 0x0000000000739fb5 in captured_main_1 (context=0x7fffffffd9e0)
    at /data/gdb_versions/devel/src/gdb/main.c:1219
#20 0x000000000073a1aa in captured_main (data=0x7fffffffd9e0) at
/data/gdb_versions/devel/src/gdb/main.c:1244
#21 0x000000000073a215 in gdb_main (args=0x7fffffffd9e0) at
/data/gdb_versions/devel/src/gdb/main.c:1269
#22 0x000000000041520e in main (argc=12, argv=0x7fffffffdae8) at
/data/gdb_versions/devel/src/gdb/gdb.c:32
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ada/25837] [cc-with-debug-names] gdb.ada/big_packed_array segv

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25837

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca,
                   |                            |tromey at sourceware dot org

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Bisects to:
...
commit e0802d59969339502203ad8e0d161b5f93beca73
Author: Tom Tromey <tromey@adacore.com>
Date:   Wed Apr 1 07:47:13 2020 -0600

    Avoid copying in lookup_name_info

    lookup_name_info always copies the name that is passed in.  However,
    normally a copy is not needed.  This patch changes this class to avoid
    copying.  This required changing the "name" method to return something
    else; I chose a gdb::string_view, to avoid excessive calls to strlen
    in the code using the lookup_name_info.  However, as this class does
    not allow an arbitrary string_view, I've also added a c_str method
    that guarantees a \0-terminated result -- a pedantic difference but
    one that respects the string_view contract, IMO.

    gdb/ChangeLog
    2020-04-01  Tom Tromey  <tromey@adacore.com>

            * symtab.h (class lookup_name_info) <lookup_name_info>: Change
            "name" parameter to rvalue reference.  Initialize m_name_holder.
            <lookup_name_info>: New overloads.
            <name>: Return gdb::string_view.
            <c_str>: New method.
            <make_ignore_params>: Update.
            <search_name_hash>: Update.
            <language_lookup_name>: Return const char *.
            <m_name>: Change type.
            * symtab.c (demangle_for_lookup_info::demangle_for_lookup_info)
            (demangle_for_lookup_info::demangle_for_lookup_info): Update.
            (lookup_name_info::match_any): Update.
            * psymtab.c (match_partial_symbol, lookup_partial_symbol):
            Update.
            * minsyms.c (linkage_name_str): Update.
            * language.c (default_symbol_name_matcher): Update.
            * dwarf2/read.c (mapped_index_base::find_name_components_bounds):
            Update.
            * ada-lang.c (ada_fold_name): Change parameter to string_view.
            (ada_lookup_name_info::ada_lookup_name_info): Update.
            (literal_symbol_name_matcher): Update.
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ada/25837] [cc-with-debug-names] gdb.ada/big_packed_array segv

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25837

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
I am not sure why this works normally.
The hack in get_symbol_name_matcher seems to be biting
and causing us not to find "pck__t" in the index.
It is definitely there:

[ 79] #145c9275 pck__t:
        <4> DW_TAG_structure_type DW_IDX_compile_unit=1 DW_IDX_GNU_internal=1
        <1> DW_TAG_typedef DW_IDX_compile_unit=1 DW_IDX_GNU_internal=1


However, it's still early, so I am not completely sure
what is going wrong.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ada/25837] [cc-with-debug-names] gdb.ada/big_packed_array segv

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25837

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
See
https://sourceware.org/legacy-ml/gdb-patches/2019-02/msg00255.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ada/25837] [cc-with-debug-names] gdb.ada/big_packed_array segv

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25837

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
It works if I do this:

diff --git a/gdb/language.c b/gdb/language.c
index c13fd1a406a..9b916b55e1e 100644
--- a/gdb/language.c
+++ b/gdb/language.c
@@ -740,9 +740,9 @@ get_symbol_name_matcher (const language_defn *lang,
   /* If currently in Ada mode, and the lookup name is wrapped in
      '<...>', hijack all symbol name comparisons using the Ada
      matcher, which handles the verbatim matching.  */
-  if (current_language->la_language == language_ada
-      && lookup_name.ada ().verbatim_p ())
-    return current_language->la_get_symbol_name_matcher (lookup_name);
+  /* if (current_language->la_language == language_ada */
+  /*     && lookup_name.ada ().verbatim_p ()) */
+  /*   return current_language->la_get_symbol_name_matcher (lookup_name); */

   if (lang->la_get_symbol_name_matcher != nullptr)
     return lang->la_get_symbol_name_matcher (lookup_name);



However, I don't know if that's really correct.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ada/25837] [cc-with-debug-names] gdb.ada/big_packed_array segv

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25837

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
That patch causes

gdb.ada/bp_c_mixed_case.exp: p <MixedCaseFunc>, in Ada: PASS => FAIL

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ada/25837] [cc-with-debug-names] gdb.ada/big_packed_array segv

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25837

--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
The issue in that regression seems to be that the
symbol is defined for C, not Ada, so it isn't matched.
Maybe the DWARF reader should be creating an Ada
symbol here.

 <2><154e>: Abbrev Number: 3 (DW_TAG_subprogram)
    <154f>   DW_AT_external    : 1
    <154f>   DW_AT_name        : (indirect string, offset: 0x21d8):
foo_h731_021__c_func
    <1553>   DW_AT_decl_file   : 1
    <1554>   DW_AT_decl_line   : 17
    <1555>   DW_AT_decl_column : 14
    <1556>   DW_AT_linkage_name: (indirect string, offset: 0x201d):
MixedCaseFunc
    <155a>   DW_AT_declaration : 1


I didn't debug here but I assume the "declaration" setting
is preventing this.  But maybe it shouldn't when the name
and the mangled name are clearly different.


Or maybe I should just try to understand why the patch in
question could even cause this regression.  It doesn't seem
like that should be possible.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ada/25837] [cc-with-debug-names] gdb.ada/big_packed_array segv

[brobecker at gnat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25837

Joel Brobecker <brobecker at gnat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brobecker at gnat dot com

--- Comment #7 from Joel Brobecker <brobecker at gnat dot com> ---
Tom said:
> The issue in that regression seems to be that the
> symbol is defined for C, not Ada, so it isn't matched.
> Maybe the DWARF reader should be creating an Ada
> symbol here.

Looking at the testcase, the `MixedCaseFunc' symbol is defined
in a unit written in C, so it's normal that GDB would know it as
a C symbol.

Regardless of the symbol's language, I would still expect GDB's "ada"
language interpreter to find any symbol via the `<...>' angle bracket
notation.

I haven't looked at this into more details, so can't say more...

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ada/25837] [cc-with-debug-names] gdb.ada/big_packed_array segv

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25837

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |tromey at sourceware dot org

--- Comment #8 from Tom Tromey <tromey at sourceware dot org> ---
I think I finally found the bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ada/25837] [cc-with-debug-names] gdb.ada/big_packed_array segv

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25837

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom Tromey from comment #8)
> I think I finally found the bug.

https://sourceware.org/pipermail/gdb-patches/2020-April/167790.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ada/25837] [cc-with-debug-names] gdb.ada/big_packed_array segv

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25837

--- Comment #10 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ecc6c6066b5cdd4663413e0bd6ef8deea1a8c889

commit ecc6c6066b5cdd4663413e0bd6ef8deea1a8c889
Author: Tom Tromey <tromey@adacore.com>
Date:   Thu Apr 23 07:19:43 2020 -0600

    Fix Ada crash with .debug_names

    PR ada/25837 points out a crash in the gdb testsuite when .debug_names
    is used.  You can reproduce like:

        runtest --target_board=cc-with-debug-names \
            gdb.ada/big_packed_array.exp

    The bug was introduced by commit e0802d599 ("Avoid copying in
    lookup_name_info").  The problem is that the return type of
    language_lookup_name changed, but in a way that didn't cause existing
    callers to trigger a compilation error.  Previously, it returned a
    "const string &", but after it returned a "const char *".  This caused
    a string to be created in dw2_expand_symtabs_matching_symbol, but one
    that had too short of a lifetime; so eventually the matcher cache
    would wind up with invalid data.

    This patch fixes the problem by updating the callers to use the new
    type.

    Tested on x86-64 Fedora 30.

    gdb/ChangeLog
    2020-04-23  Tom Tromey  <tromey@adacore.com>

            PR ada/25837:
            * dwarf2/read.c (dw2_expand_symtabs_matching_symbol): Store a
            "const char *", not a "const std::string &".
            <name_and_matcher::operator==>: Update.
            * unittests/lookup_name_info-selftests.c: Change type of
            "result".

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug ada/25837] [cc-with-debug-names] gdb.ada/big_packed_array segv

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=25837

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |10.1
             Status|NEW                         |RESOLVED

--- Comment #11 from Tom Tromey <tromey at sourceware dot org> ---
Fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.