Comment 1:

Did you read http://golang.org/doc/gdb ?
In particular: " ... optimizations can sometimes make debugging with gdb harder. To
disable them when debugging, pass the flags -gcflags "-N -l" to the go command used to
build the code being debugged."
Alex

Comment 2 by SmileKZS:

Sorry -- I didn't include the flags while I should have.
Nevertheless the problem persists.
```
C:\Users\xxxxxxxx\Desktop>go build -gcflags "-N -l" test.go
C:\Users\xxxxxxxx\Desktop>gdb test.exe
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>;...
Reading symbols from C:\Users\xxxxxxxx\Desktop/test.exe...done.
Loading Go Runtime support.
(gdb) break main.main
Breakpoint 1 at 0x401000: file C:/Users/xxxxxxxx/Desktop/test.go, line 5.
(gdb) r
Starting program: C:\Users\xxxxxxxx\Desktop/test.exe
[New Thread 3900.0x133c]
Breakpoint 1, main.main () at C:/Users/xxxxxxxx/Desktop/test.go:5
5       func main() {
(gdb) n
6               println(S)
(gdb)
[New Thread 3900.0x11ac]
1234
7               S = S + "5"
(gdb)
8               println(S)
(gdb) p S
No symbol "S" in current context.
(gdb) info goroutines
```
then crashes.

Comment 3:

P is not local variable, it is defined inside package main. Try "p main.S" instead of "p
S".
I don't know about "... then crashes".
Alex

Comment 4 by SmileKZS:

I did try this, though.
```
(gdb) p main.S
Attempt to extract a component of a value that is not a structure.
```
Yes -- after `info goroutines` it crashes without any information emitted.

Comment 5:

p 'main.S'
as main.S is the symbol name.

Comment 6 by SmileKZS:

@minux
Yes this works now. At last!
However `info goroutines`, or `p $len('main.s')` still crashes. Any idea?

Comment 7:

@alex.brainman, can you reproduce the crash on windows?
debugging the program on darwin does indicate there is a problem:
when i do this:
b 'main.main'
r
n
n
n
p s
gdb hangs (even if i don't source runtime-gdb.py).

Comment 8:

note: to debug the program you need to compile it with
go build -gcflags "-N -l" test.go

Comment 9 by SmileKZS:

@minux
I've tested both with and without `-gcflags "-N -l"` on two Windows 8 amd64 boxes. All
crashes I encounter seem to be caused by python interop.

Comment 10:

minux,
Here is my gdb session:
C:\go\path\mine\src\t>c:\bin\gdb.exe main.exe
GNU gdb (GDB) 7.5.50.20130118
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>;.
This binary was built by Equation Solution <http://www.Equation.com>;...
Reading symbols from C:\go\path\mine\src\t\main.exe...done.
(gdb) b 'main.main'
Breakpoint 1 at 0x401000: file C:/go/path/mine/src/t/main.go, line 6.
(gdb) r
Starting program: C:\go\path\mine\src\t\main.exe
[New Thread 1536.0x5c4]
Breakpoint 1, main.main () at C:/go/path/mine/src/t/main.go:6
6       func main() {
(gdb) n
7               go print(I)
(gdb) n
[New Thread 1536.0x1c8c]
8               s := S
(gdb) n
9               print(s)
(gdb) p s
$1 = 0x420cb8 "abc"
(gdb)

Comment 11:

We could use a gdb expert.

Labels changed: added go1.3maybe, expertneeded.

Status changed to Accepted.

Comment 12:

Labels changed: removed go1.3maybe.

Comment 13:

Labels changed: added go1.3maybe.

Comment 14:

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

Comment 15:

Labels changed: added repo-main.

Comment 16:

Labels changed: added gdb.