This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/18141] New: massive perf issue trying to lookup namespaces in STRUCT_DOMAIN with gdb_index


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]