Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

misc/gdb: freezes and consumes CPU when using "info locals" #6598

Open
gopherbot opened this issue Oct 16, 2013 · 6 comments
Open

misc/gdb: freezes and consumes CPU when using "info locals" #6598

gopherbot opened this issue Oct 16, 2013 · 6 comments
Milestone

Comments

@gopherbot
Copy link

by newton688:

Before filing a bug, please check whether it has been fixed since the
latest release. Search the issue tracker and check that you're running the
latest version of Go:

Run "go version" and compare against
http://golang.org/doc/devel/release.html  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

Thanks.

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. Compile a relatively large Go program (e.g. github.com/sirnewton01/godev) with the go
build/install -gcflags "-N -l" option recommended here:
http://golang.org/doc/gdb
2. Launch gdb providing the path to the program binary
2. Set a breakpoint in a section where there are plenty of complex local variables (e.g.
file.go:173 in the godev project)
3. Run the program and make it hit the breakpoint (e.g. navigate to
http://127.0.0.1:2022/navigate/table.html# and expand different folders)
4. After the breakpoint it hit issue an "info locals" command and try to page
through the full list of local variables

What is the expected output?
It is expected that uninitialized variables should show up albeit in an undefined state
(e.g. weird characters, 0x0, or just blank).

What do you see instead?
Instead, gdb freezes. Only Ctrl-C seems to bring it back. When using an application that
uses gdb/MI for a GUI interface gdb is totally unresponsive.

Which compiler are you using (5g, 6g, 8g, gccgo)?
gc

Which operating system are you using?
Ubuntu 12.04

Which version are you using?  (run 'go version')
go version devel +f4d1cb8d9a91 Thu Sep 19 22:34:33 2013 +1000 linux/amd64
-This is 1.2RC1 according to the godeb distribution

Please provide any additional information below.
I poked around in the runtime-gdb.py script and found that the to_string() of the
StringTypePrinter appears to the the culprit for the excessive CPU consumption. If I
change the implementation of this function the following the CPU problems disappear:

        def to_string(self):
                l = int(self.val['len'])
                if l < 102400 and l > -1:
                        return self.val['str'].string("utf-8", "ignore", l)
                return self.val['len']
@rsc
Copy link
Contributor

rsc commented Oct 18, 2013

Comment 1:

Labels changed: added priority-later, go1.3, removed priority-triage.

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 2:

Labels changed: added release-go1.3.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 3:

Labels changed: removed go1.3.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 4:

Labels changed: added repo-main.

@robpike
Copy link
Contributor

robpike commented Mar 5, 2014

Comment 5:

Labels changed: added gdb.

@robpike
Copy link
Contributor

robpike commented May 19, 2014

Comment 7:

Labels changed: added release-none, removed release-go1.3.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants