GDB internal error in pc_in_thread_step_range
Eli Zaretskii
eliz@gnu.org
Sat Dec 15 12:07:00 GMT 2018
Ping! Ping! Ping!
I'd really like to fix this problem for the next GDB release. Can
someone please review my findings and suggest a way of solving this?
Thanks.
> Date: Fri, 07 Dec 2018 09:21:58 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> CC: gdb-patches@sourceware.org
>
> Ping! Ping!
>
> I'd really like to fix this problem for the next GDB release. Can
> someone please review my findings and suggest a way of solving this?
>
> Thanks.
>
> > Date: Fri, 30 Nov 2018 15:42:27 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > CC: gdb-patches@sourceware.org
> >
> > Ping!
> >
> > > Date: Sun, 18 Nov 2018 18:37:13 +0200
> > > From: Eli Zaretskii <eliz@gnu.org>
> > > CC: gdb-patches@sourceware.org
> > >
> > > > Date: Mon, 20 Aug 2018 11:08:27 -0400
> > > > From: Simon Marchi <simon.marchi@polymtl.ca>
> > > > Cc: gdb@sourceware.org
> > >
> > > A reminder: this is about an internal GDB error that happens on MinGW
> > > whenever I step out of the 'main' function.
> > >
> > > > > Temporary breakpoint 1, main () at hello.c:8
> > > > > 8 printf("hello, world!");
> > > > > (gdb) n
> > > > > hello, world!9 return 0;
> > > > > (gdb)
> > > > > 10 }
> > > > > (gdb)
> > > > > 0x0040126d in __register_frame_info ()
> > > > > (gdb)
> > > > > Single stepping until exit from function __register_frame_info,
> > > > > which has no line number information.
> > > > > infrun.c:2728: internal-error: void resume_1(gdb_signal): Assertion
> > > > > `pc_in_thread_step_range (pc, tp)' failed.
> > > > > A problem internal to GDB has been detected,
> > > > > further debugging may prove unreliable.
> > > > > Quit this debugging session? (y or n)
> > > > >
> > > > > Is it a known problem?
> > > >
> > > > Not that I know of.
> > >
> > > I finally got to debugging this. It happens because:
> > >
> > > 2723 gdb_assert (pc_in_thread_step_range (pc, tp));
> > > (top-gdb) p tp->control
> > > $22 = {step_resume_breakpoint = 0x0, exception_resume_breakpoint = 0x0,
> > > single_step_breakpoints = 0x0, step_range_start = 0x0,
> > > step_range_end = 0x1, step_start_function = 0x0, may_range_step = 1,
> > > step_frame_id = {stack_addr = 0x28ff70, code_addr = 0x0,
> > > special_addr = 0x0, stack_status = FID_STACK_VALID, code_addr_p = 1,
> > > special_addr_p = 0, artificial_depth = 0}, step_stack_frame_id = {
> > > stack_addr = 0x28ff70, code_addr = 0x0, special_addr = 0x0,
> > > stack_status = FID_STACK_VALID, code_addr_p = 1, special_addr_p = 0,
> > > artificial_depth = 0}, trap_expected = 0, proceed_to_finish = 0,
> > > in_infcall = 0, step_over_calls = STEP_OVER_ALL, stop_step = 0,
> > > stop_bpstat = 0x0, stepping_command = 1}
> > >
> > > The step_range_start is zero and step_range_end is 1, which of course
> > > will not match any value of PC.
> > >
> > > What happens here is that step_1 first zeroes out these members, and
> > > then fills them by calling find_pc_line_pc_range, called from
> > > prepare_one_step. But when I step out of the main program into the
> > > library epilogue code, there's no line information, and
> > > prepare_one_step calls find_pc_partial_function, which also doesn't
> > > find any addresses. So we fill these members with zero and 1:
> > >
> > > if (address)
> > > {
> > > if (pc_in_unmapped_range (pc, section))
> > > *address = overlay_unmapped_address (cache_pc_function_low, section);
> > > else
> > > *address = cache_pc_function_low;
> > > }
> > >
> > > if (name)
> > > *name = cache_pc_function_name;
> > >
> > > if (endaddr)
> > > {
> > > if (pc_in_unmapped_range (pc, section))
> > > {
> > > /* Because the high address is actually beyond the end of
> > > the function (and therefore possibly beyond the end of
> > > the overlay), we must actually convert (high - 1) and
> > > then add one to that. */
> > >
> > > *endaddr = 1 + overlay_unmapped_address (cache_pc_function_high - 1,
> > > section);
> > > }
> > > else
> > > *endaddr = cache_pc_function_high;
> > > }
> > >
> > > The cached values are zero and 1, correspondingly.
> > >
> > > Any suggestions for how to fix this? One way would be to avoid
> > > triggering the assertion of the addresses are these two specific bogus
> > > values. Alternatively, perhaps the cached values in
> > > find_pc_partial_function should be more useful, but in that case I'd
> > > need guidance as to where and how are they supposed to be assigned, so
> > > that I could look into why they don't in this case.
> > >
> > > TIA
> > >
> >
>
More information about the Gdb-patches
mailing list