Re: gdb itself core dumps

[Ariel Burbaickij <ariel.burbaickij@gmail.com>]

OK, it crashes very close to  the initial  spot also in latest&greatest
12.1:

1048          void* __place = _Raw_bytes_alloc(__alloc).allocate(__size);
(gdb) s
__gnu_cxx::new_allocator<char>::allocate (__n=85, this=<optimized out>)
    at
/usr/src/debug/gcc-11.3.0-1/x86_64-pc-cygwin/libstdc++-v3/include/ext/new_allocator.h:103
103           allocate(size_type __n, const void* = static_cast<const
void*>(0))
(gdb) s
__wrap__Znwm (sz=85) at
/usr/src/debug/cygwin-3.3.5-1/winsup/cygwin/libstdcxx_wrapper.cc:55
55        return (*user_data->cxx_malloc->oper_new) (sz);
(gdb) s
/cygdrive/d/a/scallywag/gdb/gdb-12.1-1.x86_64/src/gdb-12.1/gdb/infrun.c:2553:
internal-error: resume_1: Assertion `pc_in_thread_step_range (pc, tp)'
failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
---------------------
/cygdrive/d/a/scallywag/gdb/gdb-12.1-1.x86_64/src/gdb-12.1/gdb/infrun.c:2553:
internal-error: resume_1: Assertion `pc_in_thread_step_range (pc, tp)'
failed.

So, now to the description of circumstances that cause it:
Program is: https://github.com/eshavlyugin/Preferans
I compiled it after some trivial fixes ( like referencing explicitly
boost:array; boost:unordered_map, even so it should not be needed, i.e. gcc
should be well able to figure out what is being used, change of the
condition if (window == null) to if (!(window)) and setting C++ language
version C++11 because of additional requirements  put on comparators --
them having to use some const in explicit -- so by and large because gcc is
too feisty at all the wrong places ;-) ). Now every time I select Game->New
in the GUI it crashes and crash seems to be related to
LocalPrefServer.cpp:395 line, so I set breakpoint there and attempted to
single-step through what appears to be platform's (Cygwin+system libraries)
bowels. Now what?

Kind Regards
Ariel Burbaickij



On Sun, Jun 26, 2022 at 3:58 PM Jon Turney <jon.turney@dronecode.org.uk>
wrote:

> On 24/06/2022 15:13, Ariel Burbaickij wrote:
> > Hello mailing list,
> >
> > I was in the middle of deep debugging session when following happened:
> >
> > 103           allocate(size_type __n, const void* = static_cast<const
> > void*>(0))
> > (gdb) s
> > __wrap__Znwm (sz=85) at
> > /usr/src/debug/cygwin-3.3.5-1/winsup/cygwin/libstdcxx_wrapper.cc:55
> > 55        return (*user_data->cxx_malloc->oper_new) (sz);
> > (gdb) s
> >
> /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.
> > A problem internal to GDB has been detected,
> > further debugging may prove unreliable.
> > ...
> > application level programm (open source under GNU) from which I stepped
> > into allocator crashes also somewhere near, so right now I am not sure
> what
> > exactly gdb stumbles upon. GDB Core file is available. How do we proceed
> > from here ?
>
> In the first place, please try the gdb 12.1 test package (available
> through cygwin setup).
>
> If that doesn't improve matters, some details about how to (simply)
> reproduce the problem would be nice.
>
>