[Bug symtab/26327] New: GDB hangs in get_builder() due to recursive ancestor pointers

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug symtab/26327] New: GDB hangs in get_builder() due to recursive ancestor pointers

Sourceware - gdb-prs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=26327

            Bug ID: 26327
           Summary: GDB hangs in get_builder() due to recursive ancestor
                    pointers
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: d.c.ddcc at gmail dot com
  Target Milestone: ---

With recent versions of gdb (somewhere around 8.x to 10.0.50.20200731-git),
I've noticed that GDB sometimes hangs when debugging C++ programs compiled with
Clang/LLVM 10.0.1. This can occur either initially when reading symbols, or
during debugging after a breakpoint fires.

I noticed a workaround was sent previously: "Fixing get_builder() function in
dwarf2/read.c", which appears to be for the same problem. I don't know what the
correct solution is wrt parsing DWARF symbols, but I'm experiencing similar
symptoms, and my stacktrace looks similar to the second one sent out by Slava.

I can provide the binary (~9MB), but not the direct source (it's 447.dealII
from SPEC CPU2006).

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug symtab/26327] GDB hangs in get_builder() due to recursive ancestor pointers

Sourceware - gdb-prs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=26327

d.c.ddcc at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |d.c.ddcc at gmail dot com

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug symtab/26327] GDB hangs in get_builder() due to recursive ancestor pointers

Sourceware - gdb-prs mailing list
In reply to this post by Sourceware - gdb-prs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=26327

d.c.ddcc at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://51.15.138.76/patch/3
                   |                            |7038/

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug symtab/26327] GDB hangs in get_builder() due to recursive ancestor pointers

Sourceware - gdb-prs mailing list
In reply to this post by Sourceware - gdb-prs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=26327

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vries at gcc dot gnu.org

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to d.c.ddcc from comment #0)
> I noticed a workaround was sent previously: "Fixing get_builder() function
> in dwarf2/read.c"

https://sourceware.org/pipermail/gdb-patches/2020-June/169471.html

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug symtab/26327] GDB hangs in get_builder() due to recursive ancestor pointers

Sourceware - gdb-prs mailing list
In reply to this post by Sourceware - gdb-prs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=26327

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--- Comment #2 from Simon Marchi <simark at simark dot ca> ---
Like I said in the original report, a reproducer program or at least binary
would be useful so we can analyze the problem and make sure we fix the problem
the right way, and not only cover up the problem.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug symtab/26327] GDB hangs in get_builder() due to recursive ancestor pointers

Sourceware - gdb-prs mailing list
In reply to this post by Sourceware - gdb-prs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=26327

--- Comment #3 from d.c.ddcc at gmail dot com ---
Created attachment 12737
  --> https://sourceware.org/bugzilla/attachment.cgi?id=12737&action=edit
447.dealII, hangs on reading symbols in GDB

#0  0x0000560a5ab7e27c in dwarf2_cu::get_builder (this=0x560a5eb32060) at
../../gdb/dwarf2/read.c:606
    dwarf2_name(die, cu) = 0x7f9fe022b8d3 "arg_list"
#1  new_symbol (die=0x560a5f391500, type=0x0, cu=0x560a5eb32060,
space=<optimized out>)
    at ../../gdb/dwarf2/read.c:21225
    dwarf2_name(die, cu) = 0x7f9fe022b8d3 "arg_list"
#2  0x0000560a5ab881a1 in process_die (die=0x560a5f391500, cu=0x560a5eb32060)
    at ../../gdb/dwarf2/read.c:10214
    dwarf2_name(die, cu) = 0x560a5f3b7200 "do_call<void
(*)(std::vector<DataOutBase::Patch<3, 3>, std::allocator<DataOutBase::Patch<3,
3> > > const&, Table<2, double>&),
boost::tuples::tuple<std::vector<DataOutBase::Patch<3, 3>,
std::allocator<DataOutBase::Patch<3, 3> > > const&, Table<2, double>&,
boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type,
boost::tuples::null_type, boost::tuples::null_type> >"
#3  0x0000560a5ab86930 in inherit_abstract_dies (die=0x560a5d66ab00,
cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:13132
#4  0x0000560a5ab86d83 in read_func_scope (die=0x560a5d66ab00,
cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:13260
#5  0x0000560a5ab88239 in process_die (die=0x560a5d66ab00, cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:10136
#6  0x0000560a5ab86d1b in read_func_scope (die=0x560a5d66aa30,
cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:13255
#7  0x0000560a5ab88239 in process_die (die=0x560a5d66aa30, cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:10136
#8  0x0000560a5ab86d1b in read_func_scope (die=0x560a5d66a950,
cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:13255
#9  0x0000560a5ab88239 in process_die (die=0x560a5d66a950, cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:10136
#10 0x0000560a5ab86d1b in read_func_scope (die=0x560a5d66a7e0,
cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:13255
#11 0x0000560a5ab88239 in process_die (die=0x560a5d66a7e0, cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:10136
#12 0x0000560a5ab86d1b in read_func_scope (die=0x560a5d6683e0,
cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:13255
#13 0x0000560a5ab88239 in process_die (die=0x560a5d6683e0, cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:10136
#14 0x0000560a5ab86d1b in read_func_scope (die=0x560a5d6682c0,
cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:13255
#15 0x0000560a5ab88239 in process_die (die=0x560a5d6682c0, cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:10136
#16 0x0000560a5ab86d1b in read_func_scope (die=0x560a5d668100,
cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:13255
#17 0x0000560a5ab88239 in process_die (die=0x560a5d668100, cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:10136
#18 0x0000560a5ab8b8cb in read_lexical_block_scope (die=0x560a5d65d420,
cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:13391
#19 0x0000560a5ab89222 in process_die (die=0x560a5d65d420, cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:10141
#20 0x0000560a5ab86d1b in read_func_scope (die=0x560a5d60a830,
cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:13255
#21 0x0000560a5ab88239 in process_die (die=0x560a5d60a830, cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:10136
#22 0x0000560a5ab8b4a9 in read_file_scope (die=0x560a5d457e90,
cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:11112
#23 0x0000560a5ab89190 in process_die (die=0x560a5d457e90, cu=0x560a5d479a30)
    at ../../gdb/dwarf2/read.c:10123
#24 0x0000560a5ab8bf03 in process_full_comp_unit (pretend_language=<optimized
out>,
    cu=0x560a5d479a30) at ../../gdb/dwarf2/read.c:9893
#25 process_queue (per_objfile=0x560a5d231940) at ../../gdb/dwarf2/read.c:9134
#26 dw2_do_instantiate_symtab (per_cu=per_cu@entry=0x560a5d470180,
    per_objfile=per_objfile@entry=0x560a5d231940,
skip_partial=skip_partial@entry=false)
    at ../../gdb/dwarf2/read.c:2411
#27 0x0000560a5ab8c457 in dw2_instantiate_symtab (per_cu=0x560a5d470180,
per_objfile=0x560a5d231940,
    skip_partial=<optimized out>) at ../../gdb/dwarf2/read.c:2434
#28 0x0000560a5ab8d10c in dw2_lookup_symbol (objfile=<optimized out>,
block_index=GLOBAL_BLOCK,
    name=0x560a5d3feaa0 "main", domain=VAR_DOMAIN) at
../../gdb/dwarf2/read.c:3623
#29 0x0000560a5ad420fb in lookup_symbol_via_quick_fns (domain=VAR_DOMAIN,
    name=0x560a5d3feaa0 "main", block_index=GLOBAL_BLOCK,
objfile=0x560a5d3fe3e0)
    at ../../gdb/symtab.c:2373
#30 lookup_symbol_in_objfile (objfile=0x560a5d3fe3e0, block_index=GLOBAL_BLOCK,
    name=0x560a5d3feaa0 "main", domain=VAR_DOMAIN) at ../../gdb/symtab.c:2522
#31 0x0000560a5ad42344 in lookup_symbol_global_or_static_iterator_cb
(objfile=<optimized out>,
    cb_data=0x7ffea086f6f0) at ../../gdb/symtab.c:2596
#32 0x0000560a5ad0b744 in svr4_iterate_over_objfiles_in_search_order
(gdbarch=<optimized out>,
    cb=0x560a5ad42320 <lookup_symbol_global_or_static_iterator_cb(objfile*,
void*)>,
    cb_data=0x7ffea086f6f0, current_objfile=0x0) at ../../gdb/solib-svr4.c:3248
#33 0x0000560a5ad3c4be in lookup_global_or_static_symbol (name=0x560a5d3feaa0
"main",
    block_index=GLOBAL_BLOCK, objfile=0x0, domain=VAR_DOMAIN) at
../../gdb/symtab.c:2641
#34 0x0000560a5ad41b6d in lookup_global_symbol (name=0x560a5d3feaa0 "main",
block=<optimized out>,
    domain=VAR_DOMAIN) at ../../gdb/symtab.c:2691
#35 0x0000560a5ad417d4 in lookup_symbol_aux (name=0x560a5d3feaa0 "main",
    match_type=match_type@entry=symbol_name_match_type::FULL,
block=block@entry=0x0,
    domain=domain@entry=VAR_DOMAIN, language=language@entry=language_c,
    is_a_field_of_this=is_a_field_of_this@entry=0x0) at ../../gdb/symtab.c:2089
#36 0x0000560a5ad41934 in lookup_symbol_in_language (name=<optimized out>,
block=block@entry=0x0,
    domain=domain@entry=VAR_DOMAIN, lang=lang@entry=language_c,
    is_a_field_of_this=is_a_field_of_this@entry=0x0) at ../../gdb/symtab.c:1881
#37 0x0000560a5ad2cf9c in set_initial_language () at ../../gdb/symfile.c:1683
#38 0x0000560a5ac41840 in catch_command_errors (command=<optimized out>,
arg=<optimized out>,
    from_tty=<optimized out>) at ../../gdb/main.c:457
#39 0x0000560a5ac435cd in captured_main_1 (context=<optimized out>) at
../../gdb/main.c:1123
#40 0x0000560a5ac4381f in captured_main (data=0x7ffea086fba0) at
../../gdb/main.c:1243
#41 gdb_main (args=args@entry=0x7ffea086fbc0) at ../../gdb/main.c:1268
#42 0x0000560a5aa57640 in main (argc=<optimized out>, argv=<optimized out>) at
../../gdb/gdb.c:32

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug symtab/26327] GDB hangs in get_builder() due to recursive ancestor pointers

Sourceware - gdb-prs mailing list
In reply to this post by Sourceware - gdb-prs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=26327

--- Comment #4 from d.c.ddcc at gmail dot com ---
I've added a problematic binary as an attachment, plus a stack trace, and the
result of manually calling `dwarf2_die(die, cu)` on a couple of the top stack
frames. Let me know if you need anything else; I could also supply a packed rr
trace of GDB loading the file, if that's useful. Note that this binary is using
musl libc with a custom loader path, so it may not be directly executable.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug symtab/26327] GDB hangs in get_builder() due to recursive ancestor pointers

Sourceware - gdb-prs mailing list
In reply to this post by Sourceware - gdb-prs mailing list
https://sourceware.org/bugzilla/show_bug.cgi?id=26327

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-08-01

--- Comment #5 from Simon Marchi <simark at simark dot ca> ---
Thanks!

The infinite can be triggered without running the binary, with:

  ./gdb -nx -readnow 447.dealII

Note that I made GDB crash in other fun ways with this binary

1. Create breakpoint on main

$./gdb -nx ~/Downloads/447.dealII
(gdb) b main
[1]    1054570 abort (core dumped)  ./gdb -nx ~/Downloads/447.dealII

2. With the index-cache

Populate the index-cache for this binary:

$ ./gdb -nx -iex "set index-cache on" ~/Downloads/447.dealII -batch

It should create this file:

~/.cache/gdb/ad3eca2473ddcca165529cecf211308a2e8f5291.gdb-index

Then, starting GDB again crashes:

$./gdb -nx -iex "set index-cache on" ~/Downloads/447.dealII -batch
[1]    1054856 abort (core dumped)  ./gdb -nx -iex "set index-cache on"
~/Downloads/447.dealII -batch

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