Hello David,
congrats on your bug fixing but gdb is pretty open that it considers it as
its own bug while running its "inferior", somewhere here:

if (tp->control.may_range_step)
{
/* If we're resuming a thread with the PC out of the step
range, then we're doing some nested/finer run control
operation, like stepping the thread out of the dynamic
linker or the displaced stepping scratch pad. We
shouldn't have allowed a range step then. */
gdb_assert (pc_in_thread_step_range (pc, tp));
}

whatever the logic behind setting may_range_step might be, it is (or should
be) as much decoupled from all the probable bugs in allocators of all the
possible flavours.

So, it should be investigated from the side of gdb maintainers too, for
sure, as I see it.

Kind Regards
Ariel Burbaickij


On Thu, Oct 20, 2022 at 10:22 AM David Allsopp <david@tarides.com> wrote:

> On Tue, 18 Oct 2022 at 20:09, Jon Turney wrote:
> >
> > On 18/10/2022 11:35, David Allsopp wrote:
> > > I'm wondering if I may be able to have some pointers for debugging what
> > > seems to be an unexpected interaction between mmap/mprotect/munmap and
> > > malloc with the OCaml runtime.
> > >
> > > At the moment, I know that we crash in malloc, so my main question is
> how to
> > > go further in gdb. I installed the cygwin-debuginfo package, but all
> I'm
> > > getting is:
> >
> > Firstly, if the crash is inside the cygwin DLL, you must follow the
> > advice in [1], and use 'set cygwin-exceptions on' to tell gdb to stop on
> > an exception inside cygwin itself.
> >
> > [1] https://cygwin.com/faq.html#faq.programming.debugging-cygwin
> >
> >
> > >
> /cygdrive/d/a/scallywag/gdb/gdb-11.2-1.x86_64/src/gdb-11.2/gdb/infrun.c:2550
> > > : internal-error: void resume_1(gdb_signal): Assertion
> > > `pc_in_thread_step_range (pc, tp)' failed.
>
> I'm not sure now which combination of stepping directly into the
> malloc call, adding set cygwin-exceptions on or switching to gdb 12.1,
> but either way I was able to get to an invalid memory access in
> mmap_alloc in malloc.cc. At this point, p was a pointer to the start
> of the 256M block which had been passed to munmap.
>
> What I then noticed from that is a bug in our code - the mmap'd region
> was actually 256M+64K but the size passed to munmap was 256M... so the
> munmap call was not releasing the entire block. Fixing that on the
> OCaml side fixes the error completely - I don't know whether what we
> were seeing before counts as a bug in Cygwin's allocator?
>
> Many thanks!
>
>
> David
>
> --
> Problem reports:      https://cygwin.com/problems.html
> FAQ:                  https://cygwin.com/faq/
> Documentation:        https://cygwin.com/docs.html
> Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple
>