Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* '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