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
I noted this while writing 53840ad, so here is a proper bug report.
This only occurs for goroutine #1, and causes a Python exception. As far as I can tell, it is because for goroutine 1, pc is valid but sp is 0x0, in runtime.allgs.sched. I am not familiar enough with the runtime to discern more currently - i.e. whether it should be fixed in the runtime, or the Python script. I have reproduced on both Linux and FreeBSD. Details are below.
But it is reproducible on Debian Unstable with vanilla packages as well.
GDB Version: GNU gdb (GDB) 7.8.2 [GDB v7.8.2 for FreeBSD]
Go version: go version devel +888d44d Wed Apr 15 12:26:24 2015 +0000 freebsd/amd64
How to reproduce:
daemon404@bb-nas:~/test$ cat test.go
package main
import "fmt"
func main() {
mapvar := make(map[string]string,5)
mapvar["abc"] = "def"
mapvar["ghi"] = "jkl"
strvar := "abc"
ptrvar := &strvar
fmt.Println("hi") // line 10
_ = ptrvar
}
daemon404@bb-nas:~/test$ gdb782 ./test
GNU gdb (GDB) 7.8.2 [GDB v7.8.2 for FreeBSD]
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http:https://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-portbld-freebsd10.1".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http:https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http:https://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test...done.
Loading Go Runtime support.
(gdb) br test.go:9
Breakpoint 1 at 0x400d5c: file /home/daemon404/test/test.go, line 9.
(gdb) r
Starting program: /usr/home/daemon404/test/test
Breakpoint 1, main.main () at /home/daemon404/test/test.go:9
9 fmt.Println("hi") // line 10
(gdb) info goroutine
* 1 running runtime.systemstack_switch
2 waiting runtime.gopark
3 waiting runtime.gopark
4 runnable runtime.runfinq
(gdb) goroutine 1 bt
#0 runtime.systemstack_switch () at /home/daemon404/go/src/runtime/asm_amd64.s:216
Backtrace stopped: Cannot access memory at address 0x0
The text was updated successfully, but these errors were encountered:
ianlancetaylor
changed the title
[runtime/gdb] Stack pointer is 0 for goroutine 1
gdb: Stack pointer is 0 for goroutine 1
Jun 3, 2015
I noted this while writing 53840ad, so here is a proper bug report.
This only occurs for goroutine #1, and causes a Python exception. As far as I can tell, it is because for goroutine 1,
pc
is valid butsp
is 0x0, inruntime.allgs.sched
. I am not familiar enough with the runtime to discern more currently - i.e. whether it should be fixed in the runtime, or the Python script. I have reproduced on both Linux and FreeBSD. Details are below.Operating System:
But it is reproducible on Debian Unstable with vanilla packages as well.
GDB Version:
GNU gdb (GDB) 7.8.2 [GDB v7.8.2 for FreeBSD]
Go version:
go version devel +888d44d Wed Apr 15 12:26:24 2015 +0000 freebsd/amd64
How to reproduce:
The text was updated successfully, but these errors were encountered: