runtime: TestGdbPython nil pointer dereference

[quinte17]

Sometimes this error occurs. (1 out of 100?)

ok      cmd/vet 2.415s

##### 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 23.308s
2016/01/09 10:08:45 Failed: exit status 1

[bradfitz]

Which OS and version? And which version of Go?

We need more information.

[ianlancetaylor]

Also, which version of gdb?

[quinte17]

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.

[quinte17]

##### 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)

[bradfitz]

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/

[ALTree]

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 : )