Discussion:
GDB internal error in pc_in_thread_step_range
Eli Zaretskii
2018-11-18 16:37:13 UTC
Permalink
Date: Mon, 20 Aug 2018 11:08:27 -0400
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
Eli Zaretskii
2018-11-30 13:42:27 UTC
Permalink
Ping!
Date: Sun, 18 Nov 2018 18:37:13 +0200
Date: Mon, 20 Aug 2018 11:08:27 -0400
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.
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
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
Eli Zaretskii
2018-12-07 07:21:58 UTC
Permalink
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
Ping!
Date: Sun, 18 Nov 2018 18:37:13 +0200
Date: Mon, 20 Aug 2018 11:08:27 -0400
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.
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
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
Loading...