aboutsummaryrefslogtreecommitdiff
path: root/gdbsupport/gdb_string_view.tcc
diff options
context:
space:
mode:
authorTom Tromey <tromey@adacore.com>2020-05-08 14:26:11 -0600
committerTom Tromey <tromey@adacore.com>2020-05-08 14:26:11 -0600
commit4f7bc5edbd3ffaad52022849d6263d982c23ff3c (patch)
treed1a4c5ee8cd682341f6488f2600ed6c652924737 /gdbsupport/gdb_string_view.tcc
parent8be4b118a9343197291d23c666f6a8ad24bce76a (diff)
downloadgdb-4f7bc5edbd3ffaad52022849d6263d982c23ff3c.zip
gdb-4f7bc5edbd3ffaad52022849d6263d982c23ff3c.tar.gz
gdb-4f7bc5edbd3ffaad52022849d6263d982c23ff3c.tar.bz2
Don't re-process a DIE in read_lexical_block_scope
A customer reported a crash in the DWARF reader. Investigation showed that the crash occurred in an unusual scenario: a function was lexically scoped within some other function -- but the inner function inlined the outer function and referred to its DIE via DW_AT_abstract_origin. With the executable in question, inherit_abstract_dies could eventually call read_lexical_block_scope, which in turn could recurse into process_die, to process a DIE that was already being read, triggering an assert. This came up once before; see: https://www.sourceware.org/ml/gdb-patches/2014-02/msg00652.html However, in this case, I don't have an easy way to reproduce. So, there is no test case. I did experiment with the failing executable. This patch fixes the bug and doesn't seem to cause other issues. For example, I can still set breakpoints on the relevant functions. gdb/ChangeLog 2020-05-08 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (read_lexical_block_scope): Don't process a DIE already being processed.
Diffstat (limited to 'gdbsupport/gdb_string_view.tcc')
0 files changed, 0 insertions, 0 deletions