* [PATCH] Don't re-process a DIE in read_lexical_block_scope
@ 2020-04-24 14:51 Tom Tromey
2020-05-08 20:25 ` Tom Tromey
0 siblings, 1 reply; 2+ messages in thread
From: Tom Tromey @ 2020-04-24 14:51 UTC (permalink / raw)
To: gdb-patches; +Cc: Tom Tromey
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-04-24 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (read_lexical_block_scope): Don't process a DIE
already being processed.
---
gdb/ChangeLog | 5 +++++
gdb/dwarf2/read.c | 11 ++++++++++-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index e89ed743543..9e4427e3cd7 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -13058,7 +13058,16 @@ read_lexical_block_scope (struct die_info *die, struct dwarf2_cu *cu)
for (child_die = die->child;
child_die != NULL && child_die->tag;
child_die = child_die->sibling)
- process_die (child_die, cu);
+ {
+ /* We might already be processing this DIE. This can happen
+ in an unusual circumstance -- where a subroutine A
+ appears lexically in another subroutine B, but A actually
+ inlines B. The recursion is broken here, rather than in
+ inherit_abstract_dies, because it seems better to simply
+ drop concrete children here. */
+ if (!child_die->in_process)
+ process_die (child_die, cu);
+ }
return;
case PC_BOUNDS_INVALID:
return;
--
2.21.1
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] Don't re-process a DIE in read_lexical_block_scope
2020-04-24 14:51 [PATCH] Don't re-process a DIE in read_lexical_block_scope Tom Tromey
@ 2020-05-08 20:25 ` Tom Tromey
0 siblings, 0 replies; 2+ messages in thread
From: Tom Tromey @ 2020-05-08 20:25 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches
>>>>> "Tom" == Tom Tromey <tromey@adacore.com> writes:
Tom> A customer reported a crash in the DWARF reader.
Tom> Investigation showed that the crash occurred in an unusual scenario: a
Tom> function was lexically scoped within some other function -- but the
Tom> inner function inlined the outer function and referred to its DIE via
Tom> DW_AT_abstract_origin. With the executable in question,
Tom> inherit_abstract_dies could eventually call read_lexical_block_scope,
Tom> which in turn could recurse into process_die, to process a DIE that
Tom> was already being read, triggering an assert.
I'm checking this in.
Tom
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-05-08 20:25 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-24 14:51 [PATCH] Don't re-process a DIE in read_lexical_block_scope Tom Tromey
2020-05-08 20:25 ` Tom Tromey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).