* 'b ::new' causes gdb 8.1 to coredump ?
@ 2018-04-21 20:57 Jason Vas Dias
2018-04-21 22:52 ` Jason Vas Dias
0 siblings, 1 reply; 3+ messages in thread
From: Jason Vas Dias @ 2018-04-21 20:57 UTC (permalink / raw)
To: gdb
I was just debugging a noddy C++ test program,
(Linux x86_64: g++ 5.4.0, glibc-2.27, binutils-2.30, gdb-8.1 )
and tried:
Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd828, envp=0x7fffffffd838) at test/tTuple.C:75
75 { MyT t;
(gdb) b ::new
cp-namespace.c:177: internal-error: block_symbol cp_lookup_bare_symbol(const language_defn*, const char*, const block*, domain_enum, int): Assertion `strstr (name, "::") == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
Please answer y or n.
cp-namespace.c:177: internal-error: block_symbol cp_lookup_bare_symbol(const language_defn*, const char*, const block*, domain_enum, int): Assertion `strstr (name, "::") == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n
This is a bug, please report it. For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.
cp-namespace.c:177: internal-error: block_symbol cp_lookup_bare_symbol(const language_defn*, const char*, const block*, domain_enum, int): Assertion `strstr (name, "::") == NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
Command aborted.
(gdb) b ::new(std::size_t)
Function "::new(std::size_t)" not defined.
(gdb) b operator ::new(size_t)
Function "operator ::new(size_t)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) b operator ::new(std::size_t)
Function "operator ::new(std::size_t)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
Is there something I'm not getting or does gdb's C++ symbol handling
leave alot to be desired ?
How to set a breakpoint at the ONE definition @ :
/usr/include/c++/5.4.0/new @ line 98 :
} // namespace std
...
void* operator new(std::size_t) _GLIBCXX_THROW (std::bad_alloc)
__attribute__((__externally_visible__));
(END QUOTE)
This symbol has the fully qualified name 'operator ::new::(std::size_t)' -
so I think GDB should be able to mangle and look it up this name in
libstdc++, especially as it has the '__externally_visible__' attribute.
Why can't it ?
I think on 'b ::new' , if on a terminal, gdb should present a list of matches for
::new(.*) , and allow user to select which to break at . Would this be
too difficult to implement ?
Thanks & Best Regards,
Jason
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: 'b ::new' causes gdb 8.1 to coredump ?
2018-04-21 20:57 'b ::new' causes gdb 8.1 to coredump ? Jason Vas Dias
@ 2018-04-21 22:52 ` Jason Vas Dias
2018-04-23 0:59 ` Simon Marchi
0 siblings, 1 reply; 3+ messages in thread
From: Jason Vas Dias @ 2018-04-21 22:52 UTC (permalink / raw)
To: gdb
RE:
> start
...
> (gdb) b ::new
> cp-namespace.c:177: internal-error: block_symbol cp_lookup_bare_symbol(const language_defn*, const char*, const block*, domain_enum, int): Assertion `strstr (name, "::") == NULL' failed.
> A problem internal to GDB has been detected,
This occurs both when I built & linked the program with the 5.4.0 compiler ,
with
'-Wl,-rpath=${PATH_TO_5_4_0_LIBS},-rpath-link=${PATH_TO_5_4_0_LIBS}' ,
while GDB 8.1.11 is built with GCC 7.3.1 , and
when built with GCC 7.3.1, with
'-Wl,-rpath=${PATH_TO_7_3_1_LIBS},-rpath-link=${PATH_TO_7_3_1_LIBS}' ,
(the two paths are quite different in my setup).
In both cases, GDB coredumps on 'b ::new' (after starting), and
fails to resolve any of:
'b ::new(std::size_t)'
'b operator ::new(std::size_t)'
'b "operator::new(std::size_t)"
'b extern "C++" "operator::new(::std::size_t)"
So how is one able to break on libstd++ C++ symbols in GDB ?
Especially 'operator ::new' - I can break on any of
{ ::malloc, ::posix_memalign, ::memalign, ::sbrk .. }
but not any form of new() . Why ?
new is a proper symbol in libstdc++ :
$ nm -C /usr/lib64/gcc/x86_64-pc-linux-gnu/7.3.1/libstdc++.so.6.0.24 | grep 'new'
...
0000000000097680 T operator new(unsigned long)
Aha! It was the '::' namespace colons!
(gdb) b "operator new(std::size_t)"
Breakpoint 2 at 0x155554c30680: file ../../../../gcc-gcc-7-branch/libstdc++-v3/libsupc++/new_op.cc, line 43.
(gdb) q
But I don't think the presence or absence of leading global namespace
'::' colons should cause GDB to coredump or fail to resolve operator
new() .
Doesn't GDB understand C++ namespaces ?
Thanks, Jason
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: 'b ::new' causes gdb 8.1 to coredump ?
2018-04-21 22:52 ` Jason Vas Dias
@ 2018-04-23 0:59 ` Simon Marchi
0 siblings, 0 replies; 3+ messages in thread
From: Simon Marchi @ 2018-04-23 0:59 UTC (permalink / raw)
To: Jason Vas Dias; +Cc: gdb
On 2018-04-21 16:57, Jason Vas Dias wrote:
> Aha! It was the '::' namespace colons!
>
> (gdb) b "operator new(std::size_t)"
> Breakpoint 2 at 0x155554c30680: file
> ../../../../gcc-gcc-7-branch/libstdc++-v3/libsupc++/new_op.cc, line
> 43.
> (gdb) q
>
>
> But I don't think the presence or absence of leading global namespace
> '::' colons should cause GDB to coredump or fail to resolve operator
> new() .
>
> Doesn't GDB understand C++ namespaces ?
GDB does understand namespaces, just try "b std::string::find" for
example.
Maybe it's my knowledge of C++ that is lacking, but I don't think
'operator ::new' is right. It would be like writing 'operator ::+'. So
(gdb) b 'operator new'
sounds right to me. This:
(gdb) b '::operator new'
should probably work too (not sure), since you could have other
operators in namespaces (foo::operator==(hello&, hello&)), but it also
hits the assert. In any case, no input should ever hit an assert, so
it's still a bug (it should be cleanly rejected).
Simon
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-04-21 22:52 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-21 20:57 'b ::new' causes gdb 8.1 to coredump ? Jason Vas Dias
2018-04-21 22:52 ` Jason Vas Dias
2018-04-23 0:59 ` Simon Marchi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox