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

cmd/compile: Debug information missing : no stack info , no variables info using gdb #8357

Open
gopherbot opened this Issue Jul 11, 2014 · 18 comments

Comments

Projects
None yet
5 participants
@gopherbot

gopherbot commented Jul 11, 2014

by guybrandw:

Since version 1.3 , I cant get debugging information .
using both linux64 , windows64/32 :
1. the variables displays values with no correlation to the real value (fmt.Print()
displays the right values) .
2. the call stack displays only the last step of the stack , other steps are displayed
as ???? .

I have uninstalled Go 1.3 , installed 1.21 and both problems were "solved" .
reinstalled 1.3 , the problem returned .

attached prinshots of simple code , the variables displayed in LiteIde , the stack , and
print function of the gdb .

to make sure , I have tried the same installing the Zues IDE , same problems reproduced .

Attachments:

  1. debugIssue.png (37441 bytes)
@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Jul 11, 2014

Comment 1:

Note the beginning of http://golang.org/doc/gdb .

Labels changed: added repo-main, release-none, gdb.

@gopherbot

This comment has been minimized.

gopherbot commented Jul 11, 2014

Comment 2 by guybrandw:

Thanks very much on the fast reply .
SO , just to see that I understand correctly :
If GO 1.2.1 does show the debug info , and GO 1.3 does not
is there no other way to see it , any alternative for the gdb ? is there any big
differences between gc / gcc ?
or to sum it up , are my alternatives using fmt.Print every other line , or using 1.2.1 ?
Thanks .
@robpike

This comment has been minimized.

Contributor

robpike commented Jul 18, 2014

Comment 3:

The report is unclear but there's definitely something funny going on. Given the snippet
in the image I wrote this file:
http://play.golang.org/p/islHo1hsMN
package main
import (
    "fmt"
)
func main() {
    a := 6
    fmt.Println(a)
    sub(a)
}
func sub(a int) {
    a = 7
    subsub(a)
}
func subsub(a int) {
    a = 8
    fmt.Println(a)
}
I compiled it at tip (1.3+) and at 1.2, and then ran gdb and set a breakpoint at
'main.subsub'. With 1.3, bt prints
#0  main.subsub (a=7) at /home/r/bug.go:18
#1  0x0000000000400cce in main.sub (a=7) at /home/r/bug.go:15
#2  0x0000000000400c8f in main.main () at /home/r/bug.go:10
while with 1.2, bt prints
#0  main.subsub (a=7) at /home/r/bug.go:18
#1  0x0000000000400cc9 in main.sub (a=6) at /home/r/bug.go:15
#2  0x0000000000400c92 in main.main () at /home/r/bug.go:10
Note the argument to sub has changed value between the two prints.
@gopherbot

This comment has been minimized.

gopherbot commented Jul 18, 2014

Comment 4 by guybrandw:

OK , at least your values make "some sense" , I'm getting a real awkward value (1 !!)
what OS are you on / what GO build , what GBD build , GCC flags ?
any suggestions on using something other than gdb ?
I've been actually thinking about building some tool, but I don't see how I do that
without altering the code (not enough support in runtime/debug to integrate to the
runtime's variables , or am I missing something ?)
 Thanks .
@gopherbot

This comment has been minimized.

gopherbot commented Aug 9, 2014

Comment 5 by ziyouchutuwenwu:

i have the same problem, version 1.22 show vars ok, 1.3 not work, sometime could not
break on source file
@gopherbot

This comment has been minimized.

gopherbot commented Aug 20, 2014

Comment 6 by ignatovs:

The same issue for me.
@gopherbot

This comment has been minimized.

gopherbot commented Aug 21, 2014

Comment 7 by simon.ishai:

Hi,
Same thing happened to me as well (windows 32/64)
Version 1.2.1 showed vars and stack in a proper way, but after I've upgraded to the
version 1.3, the debug info became unavailable.
I hope that this issue will get more attention, because it is very unconvenient
situation which holds me from upgrading my setup to the newest version (now 1.3.1)
Simon
@gopherbot

This comment has been minimized.

gopherbot commented Oct 2, 2014

Comment 8 by ben.lubar:

With go1.3.3 linux/amd64 using the same steps as r:
#0  main.subsub (a=7) at [omitted]/main.go:18
#1  0x0000000000400cce in main.sub (a=4197519) at [omitted]/main.go:15
#2  0x0000000000000007 in ?? ()
#3  0x0000000000400c8f in main.main () at [omitted]/main.go:10
@gopherbot

This comment has been minimized.

gopherbot commented Oct 7, 2014

@gopherbot

This comment has been minimized.

gopherbot commented Nov 13, 2014

Comment 10 by anneagile:

I'm  concerned that this issue is from July but still says 'New' despite that numerous
people have reproduced it. How would that status be changed? Are there enough
maintainers to read the tickets? 
I'm  new so I'm trying to get a sense of how fast the project is moving/fixing things.
Debugging is always on my hot list, so here I am. :)
thank you! 
Anne
ps  Remark #9 might be a spam post.
@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Nov 13, 2014

Comment 11:

The project is moving fast and fixing things, but gdb support is a known problem area. 
See http://golang.org/doc/gdb .  I don't know of anybody actively working on improving
the debug info.

Status changed to Accepted.

@gopherbot

This comment has been minimized.

gopherbot commented Nov 13, 2014

Comment 12 by guybrandw:

Do you have an alternative to suggest ?
Debugging is a fundamental issue ...
@minux

This comment has been minimized.

Member

minux commented Nov 13, 2014

Comment 13:

debugging is a fundamental issue, but
debugging using gdb is not.
also, in a concurrent setting, stop the
world debugging is not suitable anyway.
@gopherbot

This comment has been minimized.

gopherbot commented Nov 13, 2014

Comment 14 by guybrandw:

So what do you suggest instead ?
@gopherbot

This comment has been minimized.

gopherbot commented Nov 13, 2014

Comment 15 by peter@dalinis.com:

https://github.com/derekparker/delve/
I have been using this, and it works well enough for me.
@gopherbot

This comment has been minimized.

gopherbot commented Nov 13, 2014

Comment 16 by guybrandw:

Thanks , I will try it with the Linux debugging , any similar options for OSX and/or
windows debugging ?
@gopherbot

This comment has been minimized.

gopherbot commented Nov 13, 2014

Comment 17 by peter@dalinis.com:

The author of delve has an open ticket for osx support.  No idea for
Windows.
@gopherbot

This comment has been minimized.

gopherbot commented Nov 15, 2014

Comment 18 by eidmanna:

Debugging somehow is very essential!!!
Is is possible to use this debugger https://github.com/derekparker/delve/ in combination
with liteide https://github.com/visualfc/liteide?

@rsc rsc removed the gdb label Apr 10, 2015

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc removed release-none labels Apr 10, 2015

@rsc rsc changed the title from cmd/gc: Debug information missing : no stack info , no variables info using gdb to cmd/compile: Debug information missing : no stack info , no variables info using gdb Jun 8, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment