Bug 541093

Summary:	gdb hangs when printing a class member
Product:	[Fedora] Fedora	Reporter:	Josh Stone <jistone>
Component:	gdb	Assignee:	Jan Kratochvil <jan.kratochvil>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	12	CC:	jan.kratochvil, pmuldoon, swagiaal, tromey
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	7.0-8.fc12	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-12-03 20:53:30 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Josh Stone 2009-11-24 23:28:21 UTC

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.

Comment 1 Tom Tromey 2009-11-24 23:31:58 UTC

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

Comment 2 Sami Wagiaalla 2009-11-25 19:21:37 UTC

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)

Comment 3 Josh Stone 2009-11-25 20:08:55 UTC

(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...

Comment 4 Josh Stone 2009-11-25 20:41:19 UTC

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.

Comment 5 Sami Wagiaalla 2009-11-25 21:10:40 UTC

Great!.. it hangs for me too.. the search is probably doing something unnecessary
I will look into it.

Comment 6 Jan Kratochvil 2009-12-03 16:41:02 UTC

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

Comment 7 Fedora Update System 2009-12-03 16:42:07 UTC

gdb-7.0-8.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/gdb-7.0-8.fc12

Comment 8 Josh Stone 2009-12-03 19:21:13 UTC

Confirmed, I pulled the new gdb from koji and the slowness is gone.  Thanks!

Comment 9 Sami Wagiaalla 2009-12-03 20:53:30 UTC

Great!.. thanks

Comment 10 Fedora Update System 2009-12-04 23:40:06 UTC

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.