On s390x I ran into: ... (gdb) PASS: gdb.stabs/gdb11479.exp: forced_stabs: set breakpoints continue^M Continuing.^M Recursive internal problem.^M ^@ERROR: GDB process no longer exists GDB process exited with wait status 2741 exp9 0 1 UNRESOLVED: gdb.stabs/gdb11479.exp: forced_stabs: stop at first breakpoint in \ test2 function ... With gdb we find that it's a segfault: ... Thread 1 "gdb" received signal SIGSEGV, Segmentation fault. 0x00000000014ae41a in std::vector<call_site*, std::allocator<call_site*> >::begin (this=0x0) at /usr/include/c++/7/bits/stl_vector.h:573 573 { return const_iterator(this->_M_impl._M_start); } ... due to: ... (gdb) down #5 0x0000000001bc339c in compunit_symtab::find_call_site (this=0x420a450, pc=16779034) at /dev/shm/vries/gdb/src/gdb/symtab.c:401 401 if (auto it = m_call_site_htab->find (static_cast<unrelocated_addr> (pc - delta)); (gdb) p m_call_site_htab $1 = (call_site_htab_t *) 0x0 (gdb) ... Looks like a regression since commit de2b4ab50de ("Convert dwarf2_cu::call_site_htab to new hash table"), which did: ... call_site * compunit_symtab::find_call_site (CORE_ADDR pc) const { - if (m_call_site_htab == nullptr) - return nullptr; - ...
Created attachment 15813 [details] gdb.log
Created attachment 15814 [details] overloads exec, gzipped
(In reply to Tom de Vries from comment #0) > On s390x I ran into: > ... > (gdb) PASS: gdb.stabs/gdb11479.exp: forced_stabs: set breakpoints > continue^M > Continuing.^M > Recursive internal problem.^M > ^@ERROR: GDB process no longer exists > GDB process exited with wait status 2741 exp9 0 1 > UNRESOLVED: gdb.stabs/gdb11479.exp: forced_stabs: stop at first breakpoint > in \ > test2 function > ... > > With gdb we find that it's a segfault: > ... > Thread 1 "gdb" received signal SIGSEGV, Segmentation fault. > 0x00000000014ae41a in std::vector<call_site*, std::allocator<call_site*> > >::begin (this=0x0) at /usr/include/c++/7/bits/stl_vector.h:573 > 573 { return const_iterator(this->_M_impl._M_start); } > ... > due to: > ... > (gdb) down > #5 0x0000000001bc339c in compunit_symtab::find_call_site (this=0x420a450, > pc=16779034) at /dev/shm/vries/gdb/src/gdb/symtab.c:401 > 401 if (auto it = m_call_site_htab->find (static_cast<unrelocated_addr> > (pc - delta)); > (gdb) p m_call_site_htab > $1 = (call_site_htab_t *) 0x0 > (gdb) > ... > > Looks like a regression since commit de2b4ab50de ("Convert > dwarf2_cu::call_site_htab to new hash table"), which did: > ... > call_site * > compunit_symtab::find_call_site (CORE_ADDR pc) const > { > - if (m_call_site_htab == nullptr) > - return nullptr; > - > ... I see no good reason to remove that `if`. My guess is that I tried to make `m_call_site_htab` not a pointer, realized I couldn't (`compunit_symtab` doesn't have a destructor that gets called, currently). I'll send a patch that reverts that bit.
Created attachment 15817 [details] gdb.log from gdb with proposed patch
The master branch has been updated by Simon Marchi <simark@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=22a7a2d12a81a4c4521d1d9996d06b7abf315acc commit 22a7a2d12a81a4c4521d1d9996d06b7abf315acc Author: Simon Marchi <simon.marchi@efficios.com> Date: Tue Dec 3 10:52:18 2024 -0500 gdb: restore nullptr check in compunit_symtab::find_call_site Commit de2b4ab50de ("Convert dwarf2_cu::call_site_htab to new hash table") removed this nullptr check for no good reason. This causes a crash if `m_call_site_htab` is not set, as shown in PR 32410. My guess is that when doing this change, I tried to make `m_call_site_htab` not a pointer, removed this check, then realized it wasn't so obvious, and forgot to re-add the check. Change-Id: I455e00cdc0519dfb412dc7826d17a839b77aae69 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32410 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Tom de Vries <tdevries@suse.de>
Fixed.