gdb itself core dumps

gdb itself core dumps

[Ariel Burbaickij]

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 ?

Kind Regards
Ariel Burbaickij

Re: gdb itself core dumps

[Jon Turney]

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.

Re: gdb itself core dumps

[Ariel Burbaickij]

OK, thank you for your reply. Will do and will let you know.
Reproducibility, should details of it be needed, is not an issue as the
program I tried to debug is open-source and easily available.

Kind Regards
Ariel Burbaickij

On Sunday, June 26, 2022, 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.
>
>

Re: gdb itself core dumps

[Ariel Burbaickij]

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

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