Description of problem: GDB is hanging on me when I try to print members of my class. I can print *p and see all members, but print p->foo will hang gdb (regardless of whether foo is a correct name). Debugging gdb shows it to be stuck in deeply nested cp_lookup_symbol_imports. I wasn't able to induce this with a small testcase, but you can see it on the F12 systemtap-1.0-2 packages, as I'll describe below. (You'll need kernel-debuginfo too for systemtap to get far enough.) Version-Release number of selected component (if applicable): gdb-7.0-3.fc12.x86_64 How reproducible: always Steps to Reproduce: 1. gdb /usr/bin/stap 2. b dwflpp::literal_stmt_for_local 3. r -L syscall.open (breakpoint is hit) 4. print *e 5. print e->base_name - or even: print e->non_existent_field Actual results: Step 4 prints all members just fine, but step 5 hangs forever. Expected results: It should just print the string in e->base_name.
On irc, Josh said: <jistone> I looked briefly at debugging on the stuck gdb, and it seems to be stuck in cp_lookup_symbol_imports
I am looking into this but I can't reproduce I installed systemtap-* but I get this: $ gdb /usr/bin/stap -ex 'b dwflpp::literal_stmt_for_local' -ex 'r -L syscall.open' -ex "print *e" GNU gdb (GDB) Fedora (7.0-3.fc12) [...] Breakpoint 1 at 0x119b08: file dwflpp.cxx, line 2311. [...] semantic error: no match while resolving probe point syscall.open Detaching after fork from child process 4204. Program exited with code 01. No symbol "e" in current context. (gdb)
(In reply to comment #2) > I am looking into this but I can't reproduce I installed systemtap-* > but I get this: > > $ gdb /usr/bin/stap -ex 'b dwflpp::literal_stmt_for_local' -ex 'r -L > syscall.open' -ex "print *e" > GNU gdb (GDB) Fedora (7.0-3.fc12) > [...] > Breakpoint 1 at 0x119b08: file dwflpp.cxx, line 2311. > [...] > semantic error: no match while resolving probe point syscall.open > Detaching after fork from child process 4204. Probably some of what you elided was stap complaining that it couldn't find kernel-debuginfo. Let me see if I can find a different breakpoint that requires less setup...
Here's a simpler example in main(): $ gdb /usr/bin/stap -ex 'b main.cxx:860' -ex r -ex 'p s.kernel_release' [...] Breakpoint 1, main (argc=<value optimized out>, argv=<value optimized out>) at main.cxx:860 860 usage(s, 1); [hangs...] Here "s" is a local variable, which can be printed just fine as a whole, yet hangs when trying to print a single member. However, as I was typing this, the command finally did complete and print the correct value. Judging from top, it took over 2 minutes of CPU time before it resolved the value. So it's not really a hang, but perhaps a very inefficient search. A breakpoint on usage() instead, which is taking the same "s" as a reference, can print individual members with no noticeable delay.
Great!.. it hangs for me too.. the search is probably doing something unnecessary I will look into it.
Archer fixby Sami: http://sourceware.org/gdb/wiki/ArcherBranchManagement f3e1558f5fe481a645f628a05197beb76c063b6a * Thu Dec 03 2009 Jan Kratochvil <jan.kratochvil> - 7.0-8.fc12 - Fix slowness/hang when printing some variables (Sami Wagiaalla, BZ 541093). - archer-jankratochvil-fedora12 commit: 6817a81cd411acc9579f04dcc105e9bce72859ff
gdb-7.0-8.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/gdb-7.0-8.fc12
Confirmed, I pulled the new gdb from koji and the slowness is gone. Thanks!
Great!.. thanks
gdb-7.0-8.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.