From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8512 invoked by alias); 6 Sep 2010 23:27:09 -0000 Received: (qmail 8503 invoked by uid 22791); 6 Sep 2010 23:27:08 -0000 X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_50,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-iw0-f169.google.com (HELO mail-iw0-f169.google.com) (209.85.214.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 06 Sep 2010 23:27:03 +0000 Received: by iwn33 with SMTP id 33so6848659iwn.0 for ; Mon, 06 Sep 2010 16:27:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.166.9 with SMTP id k9mr6969584iby.127.1283815621960; Mon, 06 Sep 2010 16:27:01 -0700 (PDT) Received: by 10.231.159.209 with HTTP; Mon, 6 Sep 2010 16:27:01 -0700 (PDT) Date: Mon, 06 Sep 2010 23:27:00 -0000 Message-ID: Subject: Massive slowdown printing values in gdb-7.1 From: Srinath Avadhanula To: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-09/txt/msg00039.txt.bz2 Hi, I have been testing gdb 7.1 lately and have noticed that under some circumstances (which I have been unable to reproduce with a simple program), it is taking extremely long (~ 30 seconds) to print a simple expreession such as (gdb) p s->graph where s is a symbol of type "SubsystemBlock" and graph is a sub-field of the structure SubsystemBlock. This used to be pretty much instantaneous in gdb 6.8. I tried the sampling method described at [1] to find out where gdb might be spending the most time. I found out that the five times I interrupted gdb in the middle of the printing, I got almost the same stack: ----------------- %< --------------------------- #0 0x00000000004556d5 in strcmp_iw_ordered (string1=0x29eda318 "pir::PathBalanceChecker::visit(pir::BlockComp&)", string2=0x7fffab13ade0 "getenv::graph") at utils.c:2740 #1 0x000000000050ce85 in lookup_partial_symbol (pst=, name=0x7fffab13ade0 "getenv::graph", linkage_name=0x0, global=, domain=VAR_DOMAIN) at symtab.c:1801 #2 0x000000000050d5d6 in lookup_symbol_aux_psymtabs (block_index=0, name=0x7fffab13ade0 "getenv::graph", linkage_name=0x0, domain=VAR_DOMAIN) at symtab.c:1607 #3 0x00000000005c2df1 in lookup_symbol_file (name=0x7fffab13ade0 "getenv::graph", linkage_name=0x0, block=0x296e67f0, domain=VAR_DOMAIN, anonymous_namespace=0) at cp-namespace.c:504 #4 0x00000000005c301f in cp_lookup_symbol_in_namespace (namespace=0xe3f1cd0 "getenv", name=0x2b086410 "graph", linkage_name=0x0, block=0x296e67f0, domain=VAR_DOMAIN) at cp-namespace.c:278 #5 0x00000000005c310b in cp_lookup_symbol_imports (scope=0x29eda318 "pir::PathBalanceChecker::visit(pir::BlockComp&)", name=0x7fffab13ade0 "getenv::graph", linkage_name=0x24
, block=0x1, domain=VAR_DOMAIN, search_parents=45746864) at cp-namespace.c:325 #6 0x00000000005c32bd in cp_lookup_symbol_imports (scope=0x1706a5c0 "std", name=0x2b086410 "graph", linkage_name=0x0, block=0x296e67f0, domain=VAR_DOMAIN, search_parents=0) at cp-namespace.c:370 #7 0x00000000005c32bd in cp_lookup_symbol_imports (scope=0x2966da80 "SubsystemBlock", name=0x2b086410 "graph", linkage_name=0x0, block=0x296e67f0, domain=VAR_DOMAIN, search_parents=1) at cp-namespace.c:370 #8 0x00000000005c3320 in cp_lookup_symbol_namespace (scope=0x2966da80 "SubsystemBlock", name=0x2b086410 "graph", linkage_name=0x0, block=0x296e67f0, domain=VAR_DOMAIN, search_parents=1) at cp-namespace.c:405 #9 0x000000000050d9fd in lookup_symbol_aux (name=, block=0x2966d760, domain=VAR_DOMAIN, lang=language_cplus, is_a_field_of_this=0x7fffab13b06c) at symtab.c:1406 ----------------- %< --------------------------- The strange thing about this stack is that the object "s" is of time SubsystemBlock and the graph field is a direct sub-field of that structure. However, gdb seems to be doing all sorts of lookups in various unrelated namespaces: for example in pir::PathBalanceChecker::visit etc. I don't know why gdb would be looking at that symbol at all when attempting to print "s->graph". Is this a known issue? I could provide more information if someone could tell me what. Regards, Srinath [1] http://stackoverflow.com/questions/375913/what-can-i-use-to-profile-c-code-in-linux