* gdb itself core dumps @ 2022-06-24 14:13 Ariel Burbaickij 2022-06-26 13:58 ` Jon Turney 0 siblings, 1 reply; 5+ messages in thread From: Ariel Burbaickij @ 2022-06-24 14:13 UTC (permalink / raw) To: The Cygwin Mailing List 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gdb itself core dumps 2022-06-24 14:13 gdb itself core dumps Ariel Burbaickij @ 2022-06-26 13:58 ` Jon Turney 2022-06-27 5:25 ` Ariel Burbaickij 2022-06-27 11:46 ` Ariel Burbaickij 0 siblings, 2 replies; 5+ messages in thread From: Jon Turney @ 2022-06-26 13:58 UTC (permalink / raw) To: Ariel Burbaickij, The Cygwin Mailing List 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gdb itself core dumps 2022-06-26 13:58 ` Jon Turney @ 2022-06-27 5:25 ` Ariel Burbaickij 2022-06-27 11:46 ` Ariel Burbaickij 1 sibling, 0 replies; 5+ messages in thread From: Ariel Burbaickij @ 2022-06-27 5:25 UTC (permalink / raw) To: Jon Turney; +Cc: The Cygwin Mailing List 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. > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gdb itself core dumps 2022-06-26 13:58 ` Jon Turney 2022-06-27 5:25 ` Ariel Burbaickij @ 2022-06-27 11:46 ` Ariel Burbaickij 2022-07-01 8:50 ` Ariel Burbaickij 1 sibling, 1 reply; 5+ messages in thread From: Ariel Burbaickij @ 2022-06-27 11:46 UTC (permalink / raw) To: Jon Turney; +Cc: The Cygwin Mailing List 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. > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gdb itself core dumps 2022-06-27 11:46 ` Ariel Burbaickij @ 2022-07-01 8:50 ` Ariel Burbaickij 0 siblings, 0 replies; 5+ messages in thread From: Ariel Burbaickij @ 2022-07-01 8:50 UTC (permalink / raw) To: Jon Turney; +Cc: The Cygwin Mailing List 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. >> >> ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-07-01 8:50 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-06-24 14:13 gdb itself core dumps Ariel Burbaickij 2022-06-26 13:58 ` Jon Turney 2022-06-27 5:25 ` Ariel Burbaickij 2022-06-27 11:46 ` Ariel Burbaickij 2022-07-01 8:50 ` Ariel Burbaickij
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).