This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: GDB internal error in pc_in_thread_step_range
- From: Simon Marchi <simon dot marchi at polymtl dot ca>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Sat, 15 Dec 2018 22:57:57 -0500
- Subject: Re: GDB internal error in pc_in_thread_step_range
- References: <83h8kjr8r6.fsf@gnu.org> <100001f1b27aa7d90902a75d5db37710@polymtl.ca> <83a7m6tk92.fsf@gnu.org>
Hi Eli,
Sorry for the wait. I don't really have an good answer for you, but I thought I'd
reply anyway, maybe this will help generate ideas.
On 2018-11-18 11:37 a.m., Eli Zaretskii wrote:
>> 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.
Do you mean that cache_pc_function_low is 0 and cache_pc_function_high is 1?
Do these values even make sense? They are supposed to hold a range of program
addresses, so 0 and 1 seem bogus. Maybe this is the result of something going
wrong before? It would be interesting to understand how they end up with these
values.
If find_pc_partial_function is unable to determine a proper symbol and some proper
bounds, it should return 0. So if it returns 1 but returns some wrong data,
something is fishy.
Simon