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

Jump to bottom

gdb: not showing Go strings values as initialized #6599

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

gdb: not showing Go strings values as initialized #6599

gopherbot opened this issue Oct 16, 2013 · 7 comments
Milestone
Unplanned

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. Apply the patch from issue #6598 to avoid gdb freezes
2. 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
3. Launch gdb providing the path to the program binary
4. Set a breakpoint in a section where there are plenty of complex local variables (e.g.
file.go:173 in the godev project)
5. 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)
6. Step over a few lines that initialize some of the string variables
7. Issue an "info locals" command to look at the string variables that have
been initialized

What is the expected output?
It is expected that the string values should have a reasonable length (ie. less than
6MB) given that the strings are known to be small.

What do you see instead?
Instead, the runtime-gdb.py patch reveals that the strings have incredible length (ie.
larger than 6M) even though they have been initialized to a small string. Running
"p $len(string)" is showing a large size for the strings as well. Undoing the
runtime-gdb.py patch and using the standard version causes gdb to consume tremendous CPU
trying to xfer large chunks of memory from the target process.

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

Which operating system are you using?
Ubuntu 12.04 amd64

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

Please provide any additional information below.
@rsc
Copy link
Contributor

rsc commented Oct 18, 2013

Comment 1:

info locals shows all string variables, not just the ones that have been initialized.
Are you sure that the very long ones really are initialized at the point in the program
where your breakpoint is?

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

Status changed to WaitingForReply.

@rsc
Copy link
Contributor

rsc commented Oct 18, 2013

Comment 2:

You may also need to use the -a flag to force a rebuild when using those debugging
flags. Otherwise go build or go install might decide the code is already up to date and
not recompile with -N -l.

@gopherbot
Copy link
Author

Comment 3 by newton688:

Thank you for the suggestions. To make sure that all of the binaries have the debugging
flags I deleted the executable from the $GOPATH/bin directory and removed the entire
$GOPATH/pkg directory to prevent any lingering archives from being linked in to my
executable. I am building the binary again using 'go install -gcflags "-N -l"
github.com/sirnewton01/godev'
I repeated my experiment with go 1.1.2 (according to godeb and go version). When I hit
my breakpoint I can see that many of the local strings have nonsensical values (very
large integers lengths with the patch from issue #6598). This is expected since the
strings are not yet initialized. I step over the lines that should initialize the
strings and when I invoke "info locals" I can see that, for the most part, the strings
are getting their correct values. There was one variable that never appeared to get
initialized but it was declared and used only inside a for loop. I don't know if that
makes a difference.
I repeated the above experiment using go version 1.2rc2 (according to godeb and go
version). When I hit my breakpoint this time and look at "info locals" I see that the
values have nonsensical large integer values but when I step over lines that should
initialize them they retain their nonsensical values (e.g. filePath := "").
I wonder if the line number information is somehow skewed in Go 1.2 so that I hit the
breakpoint at the wrong line of the file. It might explain that when I step over the
lines that I think I'm stepping over the initialization of the variables won't happen
until later.

@rsc
Copy link
Contributor

rsc commented Nov 27, 2013

Comment 4:

Labels changed: added go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 5:

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

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 6:

Labels changed: added repo-main.

@robpike
Copy link
Contributor

robpike commented Mar 5, 2014

Comment 7:

Labels changed: added gdb.

@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
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
3 participants
@rsc @robpike @gopherbot