This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug c++/18141] New: massive perf issue trying to lookup namespaces in STRUCT_DOMAIN with gdb_index
- From: "dje at google dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Wed, 18 Mar 2015 19:06:26 +0000
- Subject: [Bug c++/18141] New: massive perf issue trying to lookup namespaces in STRUCT_DOMAIN with gdb_index
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=18141
Bug ID: 18141
Summary: massive perf issue trying to lookup namespaces in
STRUCT_DOMAIN with gdb_index
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: c++
Assignee: unassigned at sourceware dot org
Reporter: dje at google dot com
I found another case of the classic ".gdb_index says symbol xyz exists but then
lookup not finding it" perf issue. With a few shared libraries the issue isn't
noticeable, but with 4500 shared libraries gdb is currently consuming 20GB of
memory, spent ~4 minutes cpu time (plus commensurately more wall time) and it's
still not done trying to do "print foo".
In this case gdb is doing:
#14 0x00000000008140d0 in cp_lookup_rtti_type (
name=name@entry=0x1b57ec3 "std::foo<bar>", block=block@entry=0x0)
at ../../gdb-7.9.x/gdb/cp-support.c:1446
rtti_sym = lookup_symbol (name, block, STRUCT_DOMAIN, NULL);
which later results in this call:
cp_search_static_and_baseclasses:
/* Lookup a class named KLASS. If none is found, there is nothing
more that can be done. */
klass_sym = lookup_global_symbol (klass, block, domain);
with klass being "std".
However, namespaces are in VAR_DOMAIN.
Since namespaces are recorded in .gdb_index as a type,
dw2_symtab_iter_next will find it, causing the CU that defines
"std" to be expanded, which is good, but then subsequent lookup here:
dw2_lookup_symbol:
sym = block_lookup_symbol (block, name, domain);
will fail because domain is STRUCT_DOMAIN and "std" is in VAR_DOMAIN.
The end result is that we expand one CU in each of the shared libraries that
has a .gdb_index entry for "std".
Ah, the print has now completed since I started writing this:
Command execution time: 297.609072 (cpu), 761.008252 (wall)
Space used: 25874649088 (+20380094464 for this command)
#symtabs: 622313 (+621693), #compunits: 8782 (+8774), #blocks: 4377936
(+4373024)
[I suspect the effective doubling in the number of expanded CUs (+8774) is due
to type units, but no matter.]
Here are the times with the proposed patch:
Command execution time: 0.605912 (cpu), 0.971609 (wall)
Space used: 5538639872 (+42561536 for this command)
#symtabs: 924 (+304), #compunits: 10 (+2), #blocks: 8950 (+4038)
diff --git a/gdb/cp-namespace.c b/gdb/cp-namespace.c
index 4a00cb6..d925a3b 100644
--- a/gdb/cp-namespace.c
+++ b/gdb/cp-namespace.c
@@ -355,8 +355,9 @@ cp_search_static_and_baseclasses (const char *name,
make_cleanup (xfree, nested);
/* Lookup a class named KLASS. If none is found, there is nothing
- more that can be done. */
- klass_sym = lookup_global_symbol (klass, block, domain);
+ more that can be done. KLASS could be a namespace, so always look
+ in VAR_DOMAIN. */
+ klass_sym = lookup_global_symbol (klass, block, VAR_DOMAIN);
if (klass_sym == NULL)
{
do_cleanups (cleanup);
--
You are receiving this mail because:
You are on the CC list for the bug.