| Summary: | [fission] read.c:1713: internal-error: bool dwarf2_per_objfile::symtab_set_p(const dwarf2_per_cu_data*) const: Assertion `per_cu->index < this->m_symtabs.size ()' failed. | ||
|---|---|---|---|
| Product: | gdb | Reporter: | Tom de Vries <vries> |
| Component: | symtab | Assignee: | Tom Tromey <tromey> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | tromey |
| Priority: | P2 | ||
| Version: | HEAD | ||
| Target Milestone: | 11.1 | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
(In reply to Tom Tromey from comment #1) > Looks like the same problem as bug#27893. ... though my patch for that does not fix this, so I guess not. (In reply to Tom Tromey from comment #2) > (In reply to Tom Tromey from comment #1) > > Looks like the same problem as bug#27893. > > ... though my patch for that does not fix this, so I guess not. I think this is because creating these DWO signatured_type objects modifies all_comp_units while it is being iterated. I have a patch for this. (In reply to Tom Tromey from comment #4) > I have a patch for this. The failure still reproduces for me, and the patch ( https://sourceware.org/pipermail/gdb-patches/2021-August/181479.html ) fixes it. The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d58e54bd277b90d847be09ae4b18bfdbc0dc2066 commit d58e54bd277b90d847be09ae4b18bfdbc0dc2066 Author: Tom Tromey <tom@tromey.com> Date: Wed Aug 4 12:44:10 2021 -0600 Fix two regressions caused by CU / TU merging PR symtab/28160 and PR symtab/27893 concern GDB crashes in the test suite when using the "fission" target board. They are both caused by the patches that merge the list of CUs with the list of TUs (and to a lesser degree by the patches to share DWARF data across objfiles), and the underlying issue is the same: it turns out that reading a DWO can cause new type units to be created. This means that the list of dwarf2_per_cu_data objects depends on precisely which CUs have been expanded. However, because the type units can be created while expanding a CU means that the vector of CUs can expand while it is being iterated over -- a classic mistake. Also, because a TU can be added later, it means the resize_symtabs approach is incorrect. This patch fixes resize_symtabs by removing it, and having set_symtab resize the vector on demand. It fixes the iteration problem by introducing a safe (index-based) iterator and changing the relevant spots to use it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28160 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27893 Fixed. The gdb-11-branch branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=de2143d60b9928fa19af00fe3dbb0c8b79b1237b commit de2143d60b9928fa19af00fe3dbb0c8b79b1237b Author: Tom Tromey <tom@tromey.com> Date: Wed Aug 4 12:44:10 2021 -0600 Fix two regressions caused by CU / TU merging PR symtab/28160 and PR symtab/27893 concern GDB crashes in the test suite when using the "fission" target board. They are both caused by the patches that merge the list of CUs with the list of TUs (and to a lesser degree by the patches to share DWARF data across objfiles), and the underlying issue is the same: it turns out that reading a DWO can cause new type units to be created. This means that the list of dwarf2_per_cu_data objects depends on precisely which CUs have been expanded. However, because the type units can be created while expanding a CU means that the vector of CUs can expand while it is being iterated over -- a classic mistake. Also, because a TU can be added later, it means the resize_symtabs approach is incorrect. This patch fixes resize_symtabs by removing it, and having set_symtab resize the vector on demand. It fixes the iteration problem by introducing a safe (index-based) iterator and changing the relevant spots to use it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28160 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27893 (cherry picked from commit d58e54bd277b90d847be09ae4b18bfdbc0dc2066) |
When running with target board fission, I run into: ... (gdb) file /home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/maint/maint^M Reading symbols from /home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/maint/maint...^M /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:1713: internal-error: bool dwarf2_per_objfile::symtab_set_p(const dwarf2_per_cu_data*) const: Assertion `per_cu->index < this->m_symtabs.size ()' failed.^M ... Backtrace: ... (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ffff5049a01 in __GI_abort () at abort.c:79 #2 0x0000000000b413e4 in dump_core () at gdb/utils.c:204 #3 0x0000000000b418f6 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_list_tag __va_list_tag *) (problem=0x179b940 <internal_error_problem>, file=0xef9a28 "gdb/dwarf2/read.c", line=1713, fmt=0xef8f18 "%s: Assertion `%s' failed.", ap=0x7fffffffc6b8) at gdb/utils.c:414 #4 0x0000000000b419be in internal_verror ( file=0xef9a28 "gdb/dwarf2/read.c", line=1713, fmt=0xef8f18 "%s: Assertion `%s' failed.", ap=0x7fffffffc6b8) at gdb/utils.c:439 #5 0x0000000000e1c569 in internal_error ( file=0xef9a28 "gdb/dwarf2/read.c", line=1713, fmt=0xef8f18 "%s: Assertion `%s' failed.") at gdbsupport/errors.cc:55 #6 0x000000000066d76f in dwarf2_per_objfile::symtab_set_p (this=0x1b1be10, per_cu=0x1b1a910) at gdb/dwarf2/read.c:1713 #7 0x0000000000677f57 in fill_in_sig_entry_from_dwo_entry (per_objfile=0x1b1be10, sig_entry=0x1b1a910, dwo_entry=0x21cec40) at gdb/dwarf2/read.c:5963 #8 0x0000000000678327 in lookup_dwo_signatured_type (cu=0x1acd570, sig=9824266208167740332) at gdb/dwarf2/read.c:6048 #9 0x000000000068960d in queue_and_load_dwo_tu (slot=0x21f4dd8, info=0x1acd570) at gdb/dwarf2/read.c:12735 #10 0x0000000000e54fb2 in htab_traverse_noresize (htab=0x21f4d40, callback=0x6895cb <queue_and_load_dwo_tu(void**, void*)>, info=0x1acd570) at libiberty/hashtab.c:775 #11 0x00000000006897e7 in queue_and_load_all_dwo_tus (cu=0x1acd570) at gdb/dwarf2/read.c:12771 #12 0x000000000066e70b in dw2_do_instantiate_symtab (per_cu=0x1ac22f0, per_objfile=0x1b1be10, skip_partial=false) at gdb/dwarf2/read.c:2243 #13 0x000000000066e800 in dw2_instantiate_symtab (per_cu=0x1ac22f0, per_objfile=0x1b1be10, skip_partial=false) at gdb/dwarf2/read.c:2270 #14 0x0000000000673a70 in dw2_expand_symtabs_matching_one(dwarf2_per_cu_data *, dwarf2_per_objfile *, gdb::function_view<bool(char const*, bool)>, gdb::function_view<bool(compunit_symtab*)>) (per_cu=0x1ac22f0, per_objfile=0x1b1be10, file_matcher=..., expansion_notify=...) at gdb/dwarf2/read.c:4125 #15 0x0000000000673d65 in dw2_expand_marked_cus(dwarf2_per_objfile *, offset_type, gdb::function_view<bool(char const*, bool)>, gdb::function_view<bool(compunit_symtab*)>, block_search_flags, search_domain) (per_objfile=0x1b1be10, idx=489, file_matcher=..., expansion_notify=..., search_flags=..., kind=ALL_DOMAIN) at gdb/dwarf2/read.c:4225 #16 0x00000000006741f8 in dwarf2_gdb_index::<lambda(offset_type)>::operator()(offset_type) const (__closure=0x7fffffffcee0, idx=489) at gdb/dwarf2/read.c:4355 #17 0x00000000006aacc5 in gdb::function_view<bool(unsigned int)>::<lambda(gdb::fv_detail::erased_callable, unsigned int)>::operator()(gdb::fv_detail::erased_callable, unsigned int) const (__closure=0x0, ecall=..., args#0=489) at gdb/../gdbsupport/function-view.h:263 #18 0x00000000006aacea in gdb::function_view<bool(unsigned int)>::<lambda(gdb::fv_detail::erased_callable, unsigned int)>::_FUN(gdb::fv_detail::erased_callable, unsigned int) () at gdb/../gdbsupport/function-view.h:257 #19 0x00000000006b3325 in gdb::function_view<bool (unsigned int)>::operator()(unsigned int) const (this=0x7fffffffcc50, args#0=489) at gdb/../gdbsupport/function-view.h:247 #20 0x00000000006722ed in dw2_expand_symtabs_matching_symbol(mapped_index_base &, const lookup_name_info &, gdb::function_view<bool(char const*)>, gdb::function_view<bool(unsigned int)>, dwarf2_per_objfile *) (index=..., lookup_name_in=..., symbol_matcher=..., match_callback=..., per_objfile=0x1b1be10) at gdb/dwarf2/read.c:3659 #21 0x0000000000674459 in dwarf2_gdb_index::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum_tag, search_domain) (this=0x21b50f0, objfile=0x1b2ba60, file_matcher=..., lookup_name=0x7fffffffcfe0, symbol_matcher=..., expansion_notify=..., search_flags=..., domain=VAR_DOMAIN, kind=ALL_DOMAIN) at gdb/dwarf2/read.c:4359 #22 0x0000000000a438b6 in objfile::lookup_symbol (this=0x1b2ba60, kind=GLOBAL_BLOCK, name=0x21bf800 "main", domain=VAR_DOMAIN) at gdb/symfile-debug.c:276 #23 0x0000000000a61836 in lookup_symbol_via_quick_fns (objfile=0x1b2ba60, block_index=GLOBAL_BLOCK, name=0x21bf800 "main", domain=VAR_DOMAIN) at gdb/symtab.c:2375 #24 0x0000000000a61c85 in lookup_symbol_in_objfile (objfile=0x1b2ba60, block_index=GLOBAL_BLOCK, name=0x21bf800 "main", domain=VAR_DOMAIN) at gdb/symtab.c:2523 #25 0x0000000000a61e35 in lookup_symbol_global_or_static_iterator_cb (objfile=0x1b2ba60, cb_data=0x7fffffffd360) at gdb/symtab.c:2587 #26 0x0000000000a14350 in svr4_iterate_over_objfiles_in_search_order (gdbarch=0x21bbd60, cb=0xa61db1 <lookup_symbol_global_or_static_iterator_cb(objfile*, void*)>, cb_data=0x7fffffffd360, current_objfile=0x0) at gdb/solib-svr4.c:3273 #27 0x000000000072bada in gdbarch_iterate_over_objfiles_in_search_order (gdbarch=0x21bbd60, cb=0xa61db1 <lookup_symbol_global_or_static_iterator_cb(objfile*, void*)>, cb_data=0x7fffffffd360, current_objfile=0x0) at gdb/gdbarch.c:5090 #28 0x0000000000a61fbd in lookup_global_or_static_symbol (name=0x21bf800 "main", block_index=GLOBAL_BLOCK, objfile=0x0, domain=VAR_DOMAIN) at gdb/symtab.c:2633 #29 0x0000000000a6212c in lookup_global_symbol (name=0x21bf800 "main", block=0x0, domain=VAR_DOMAIN) at gdb/symtab.c:2684 #30 0x0000000000a61a0c in language_defn::lookup_symbol_nonlocal ( this=0x17ad5a0 <c_language_defn>, name=0x21bf800 "main", block=0x0, domain=VAR_DOMAIN) at gdb/symtab.c:2444 #31 0x0000000000a60e2b in lookup_symbol_aux (name=0x21bf800 "main", match_type=symbol_name_match_type::FULL, block=0x0, domain=VAR_DOMAIN, language=language_c, is_a_field_of_this=0x0) at gdb/symtab.c:2094 #32 0x0000000000a605be in lookup_symbol_in_language (name=0x21bf800 "main", block=0x0, domain=VAR_DOMAIN, lang=language_c, is_a_field_of_this=0x0) at gdb/symtab.c:1889 #33 0x0000000000a4a10d in set_initial_language () at gdb/symfile.c:1672 #34 0x0000000000a48e61 in symbol_file_add_main_1 ( args=0x7fffffffe156 "outputs/gdb.base/maint/maint", add_flags=..., flags=..., reloff=0) at gdb/symfile.c:1213 #35 0x0000000000a48dc1 in symbol_file_add_main ( args=0x7fffffffe156 "outputs/gdb.base/maint/maint", add_flags=...) at gdb/symfile.c:1195 #36 0x000000000081ea7e in symbol_file_add_main_adapter ( arg=0x7fffffffe156 "outputs/gdb.base/maint/maint", from_tty=0) at gdb/main.c:550 #37 0x000000000081e9c8 in catch_command_errors ( command=0x81ea2f <symbol_file_add_main_adapter(char const*, int)>, arg=0x7fffffffe156 "outputs/gdb.base/maint/maint", from_tty=0, do_bp_actions=false) at gdb/main.c:523 #38 0x000000000081fb7c in captured_main_1 (context=0x7fffffffda10) at gdb/main.c:1236 #39 0x00000000008201bc in captured_main (data=0x7fffffffda10) at gdb/main.c:1343 #40 0x0000000000820227 in gdb_main (args=0x7fffffffda10) at gdb/main.c:1368 #41 0x000000000041764e in main (argc=12, argv=0x7fffffffdb18) at gdb/gdb.c:32 ... The assert triggers because: ... 1713 gdb_assert (per_cu->index < this->m_symtabs.size ()); (gdb) p per_cu->index $1 = 7 (gdb) p this->m_symtabs.size () $2 = 7 ...