You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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']
The text was updated successfully, but these errors were encountered:
by newton688:
The text was updated successfully, but these errors were encountered: