Re: GDB internal error in pc_in_thread_step_range

[Eli Zaretskii <eliz at gnu dot 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