Which OS and version? And which version of Go?

We need more information.

Also, which version of gdb?

Ubuntu 14.04.3 LTS Kernel 3.19
gcc --version: gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
gdb --version: GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
go was around 505fa7b42338f0aba7e4235acbc8274a20f3c1f0

i don't have the exact go version around anymore.

##### GOMAXPROCS=2 runtime -cpu=1,2,4
--- FAIL: TestGdbPython (0.51s)
    runtime-gdb_test.go:42: gdb version 7.7
    runtime-gdb_test.go:167: goroutine 2 bt failed: Python Exception <class 'gdb.MemoryError'> Cannot access memory at address 0x0: 
        Error occurred in Python command: Cannot access memory at address 0x0
FAIL
FAIL    runtime 21.330s
2016/01/31 22:11:47 Failed: exit status 1
$ go version
go version devel +af15bee Fri Jan 29 18:29:10 2016 +0000 linux/amd64

error is still there (after hours of running)

Just happened again:

https://storage.googleapis.com/go-build-log/fa99a6a3/linux-arm_f6c5e1c9.log

From @mdempsky's https://go-review.googlesource.com/#/c/29358/

The author of the failing test (the one that runs goroutine 2 bt), noted in the commit message that the test should be run with

goroutine 2 [...], since goroutine 1 has its stack pointer set to 0 for some reason

He opened an issue about this, #10468, where he wrote:

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

He's correct in that the cause of the Python exception is the sp having value 0x0, but it's not true that this only occurs in goroutine 1. Take for example:

package main

import (
    "fmt"
    "sync"
)

func main() {
    var wg sync.WaitGroup
    wg.Add(1)
    go func() {
        fmt.Println("hi")
        wg.Done()
    }()
    wg.Wait()

    fmt.Println("hello")
}

$ gdb ./test
[...]
(gdb) b 14
(gdb) r
(gdb) info goroutines
  1 waiting  runtime.gopark
  2 waiting  runtime.gopark
  17 waiting  runtime.gopark
  18 waiting  runtime.gopark
* 19 running  main.main.func1

bt works on goroutine 1, but it fails with goroutine 19 (the running one):

(gdb) goroutine 19 bt
#0  main.main.func1 (&wg=<error reading variable: Cannot access memory at address 0x8>)
    at /home/alberto/prova.go:13
Backtrace stopped: Cannot access memory at address 0x0

which has a 0x0 stackpointer.

Maybe the gdb-test is failing because it sometimes happens that the test is run while the tested goroutine (2) is running?

Unfortunately I wasn't able to observe the python exception with my gdb 7.11 (not even changing the test to backtrace on goroutine 1, which is usually running, causes an exception to be raised), so I can't really go on with my investigation : )

The most recent occurrence of this on the dashboard:

2017-05-25T01:55:18-a9d8d4d/linux-386-387:

--- FAIL: TestGdbPythonCgo (1.77s)
	runtime-gdb_test.go:55: gdb version 7.7
	runtime-gdb_test.go:218: goroutine 2 bt failed: Traceback (most recent call last):
		  File "/tmp/workdir/go/src/runtime/runtime-gdb.py", line 453, in invoke
		    gdb.parse_and_eval('$sp = {0}'.format(str(sp)))
		gdb.MemoryError: Cannot access memory at address 0x0
		Error occurred in Python command: Cannot access memory at address 0x0
FAIL
FAIL	runtime

This has the stack trace in it.

The exact place this is happening is a little strange, but my guess is that the MemoryError is a secondary effect of GDB updating its frame cache when $sp is set to (presumably) 0.

Maybe the gdb-test is failing because it sometimes happens that the test is run while the tested goroutine (2) is running?

That's certainly possible. The test main doesn't do much, so it's certainly possible that some of these other goroutines are still getting off the ground and haven't parked yet. Indeed, when they're running runtime.gogo sets sched.sp to 0 to avoid having a stale value around.

Really, gdb shouldn't be using gp.sched for a running goroutine. It should get the pc and sp from the M the goroutine is running on. I've got some code to do this already. I'll see if I can adapt it.

CL https://golang.org/cl/45031 mentions this issue.