-
Notifications
You must be signed in to change notification settings - Fork 18k
runtime: SIGSEGV in mstart #47441
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@cherrymui found the problem: a preemption can occur after the call to The preemption point is the first defer in Here is a test case that recreates the observed problem. In order to recreate the problem the test case uses foo1.go: package main
/*
extern void cgoTraceback(void* p);
extern void cgoSymbolizer(void* p);
extern void cgoContext(void* p);
extern void GoFunction(int);
static void callGo(int i) {
GoFunction(i);
}
*/
import "C"
import (
"fmt"
"runtime"
"sync"
"unsafe"
)
//export GoFunction
func GoFunction(i C.int) {
fmt.Sprintf("%d\n", i)
}
func main() {
runtime.SetCgoTraceback(0, unsafe.Pointer(C.cgoTraceback), unsafe.Pointer(C.cgoContext), unsafe.Pointer(C.cgoSymbolizer))
const funcs = 1e3
const calls = 1e5
var wg sync.WaitGroup
wg.Add(1)
for i := 0; i < funcs; i++ {
go func(i int) {
defer wg.Done()
for j := 0; j < calls; j++ {
C.callGo(C.int(i*calls + j))
}
}(i)
}
wg.Wait()
} foo2.c:
|
Change https://golang.org/cl/338197 mentions this issue: |
Change https://golang.org/cl/338270 mentions this issue: |
Change https://golang.org/cl/359796 mentions this issue: |
This adds a maymorestack hook that forces a preemption at every possible cooperative preemption point. This would have helped us catch several recent preemption-related bugs earlier, including #47302, #47304, and #47441. For #48297. Change-Id: Ib82c973589c8a7223900e1842913b8591938fb9f Reviewed-on: https://go-review.googlesource.com/c/go/+/359796 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: David Chase <drchase@google.com>
On some Google internal workloads on 1.17rc1, we are seeing SIGSEGVs of the form:
0x00007f596f4c0500
seems to be an address on the C stack callingmstart
, indicating we jumped into the stack.We don't have many details yet, this is still being investigated. If anyone else has seen similar crashes on 1.17, we'd love to hear.
cc @ianlancetaylor @cherrymui @aclements
The text was updated successfully, but these errors were encountered: