gccgo: seg fault if profiling signal arrives when collecting backtrace

[cherrymui]

What version of Go are you using (go version)?

gccgo (GCC) 9.0.0 20181224 (experimental)

What operating system and processor architecture are you using (go env)?

linux/amd64

What did you do?

package main

import (
	"log"
	"os"
	"runtime"
	"runtime/pprof"
)

const N = 10000

func main() {
	f, err := os.Create("/tmp/prof")
	if err != nil {
		log.Fatal(err)
	}

	pprof.StartCPUProfile(f)

	go func(){
		select {}
	}()

	buf := make([]byte, 99999)
	for i := 0; i < N; i++ {
		runtime.Stack(buf, true)
	}

	pprof.StopCPUProfile()
	f.Close()
}

This program, compiled with gccgo, crashes with high probability. Here is the stack trace at crash:

(gdb) bt
#0  0x0000000000544562 in runtime.sigtramp (sig=27, info=0x7ffff7e88bf0, context=0x7ffff7e88ac0) at /usr/local/google/home/cherryyz/src/gccgo/libgo/runtime/go-signal.c:94
#1  <signal handler called>
#2  0x00007ffff7342b3c in setcontext () from /lib/x86_64-linux-gnu/libc.so.6
#3  0x000000000040706b in runtime.gogo (newg=newg@entry=0xc0001a4a80) at /usr/local/google/home/cherryyz/src/gccgo/libgo/runtime/proc.c:292
#4  0x00000000004070f2 in runtime.getTraceback (me=me@entry=0xc000000a80, gp=gp@entry=0xc0001a4a80) at /usr/local/google/home/cherryyz/src/gccgo/libgo/runtime/proc.c:451
#5  0x000000000048feda in runtime.tracebackothers (me=me@entry=0xc000000a80) at /usr/local/google/home/cherryyz/src/gccgo/libgo/go/runtime/traceback_gccgo.go:229
#6  0x00000000004aee00 in runtime.Stack (buf=..., all=<optimized out>) at /usr/local/google/home/cherryyz/src/gccgo/libgo/go/runtime/mprof.go:812
#7  0x0000000000405bab in main.main () at p.go:26

(gdb) p gp
$1 = (G *) 0xc0001a4a80
(gdb) p gp->m
$2 = (struct m *) 0x0

The signal arrives half-way through a goroutine switch, where gp is not nil but gp->m is nil. Function getTraceback switches to gp without setting up an m. When setcontext finishes, it will be in mcall, which will call gtraceback, which will set up an m. But there is a gap and profiling signal could arrive in between. Maybe we could set up an m earlier, in getTraceback, before switching to gp.

Another possibility would be in sigtramp, treating "gp is not nil but gp->m is nil" the same as gp is nil.

Found this initially when investigating a similar seg fault with precise stack scan (with gollvm), where it uses a similar way to switch goroutine when scanning another goroutine's stack.

cc @ianlancetaylor @thanm

[gopherbot]

Change https://golang.org/cl/156037 mentions this issue: runtime: prevent deadlock when profiling signal arrives during traceback

[gopherbot]

Change https://golang.org/cl/156038 mentions this issue: runtime: in getTraceback, set gp->m before gogo

[gopherbot]

Change https://golang.org/cl/156018 mentions this issue: runtime/pprof: add a test for gccgo bug #29448

[gopherbot]

Change https://golang.org/cl/156697 mentions this issue: runtime: in doscanstackswitch, set gp->m before gogo