[PATCHv2 1/2] gdb: prevent an assertion when computing the frame_id for an inline frame
Simon Marchi
simon.marchi@polymtl.ca
Mon Jul 5 14:14:39 GMT 2021
On 2021-07-05 7:39 a.m., Pedro Alves wrote:
> Hi Andrew,
>
> I've read this, and I think you came up with a reasonable solution.
I discussed this with Andrew on IRC, and my bad, I didn't post the
summary of our discussions here.
I suggested that this was confusing because get_prev_frame_if_no_cycle
now becomes get_prev_frame_if_no_cycle_except_in_some_cases, and it
makes get_prev_frame_if_no_cycle alter its behavior based on what it
thinks its caller is doing. And it causes the inline frame's this_id
method to "lie" if it can't successfully compute the frame id, instead
of properly reporting failure. The problem, in my opinion, is that:
- inline_frame_this_id is currently not allowed to fail (return
null_frame_id)
- inline_frame_this_id uses get_prev_frame_if_no_cycle, which is
allowed to fail (return nullptr)
So the question, in my opinion, is: how to propagate the
get_prev_frame_if_no_cycle failure up the stack. I suggested that the
this_id method could throw a "FRAME_CYCLE_ERROR" in that case, caught
by the get_prev_frame_if_no_cycle call up the stack. It would then
set the last physical frame's stop reason to UNWIND_SAME_ID.
I made a prototype here, which passes Andrew's test:
https://review.lttng.org/c/binutils-gdb/+/6122
I prefer this option because it avoids adding special cases. If the id
can't be computed, this_id throws and that's it, the caller decides what
to do with it. But if people prefer the original solution, I don't
mind :).
Simon
More information about the Gdb-patches
mailing list