gdb itself core dumps

[Ariel Burbaickij]

Hello all,
any news here eventually ?

Kind Regards
Ariel Burbaickij

On Mon, Jun 27, 2022 at 1:46 PM Ariel Burbaickij <ariel.burbaickij@gmail.com>
wrote:

> 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.
>>
>>