Skip to content
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.

Sign up for GitHub

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

Jump to bottom

runtime: error on exit of program on darwin fatal error: exitsyscall: syscall frame is no longer valid #42465

Closed
tonimelisma opened this issue Nov 9, 2020 · 8 comments
Closed

runtime: error on exit of program on darwin fatal error: exitsyscall: syscall frame is no longer valid #42465

tonimelisma opened this issue Nov 9, 2020 · 8 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@tonimelisma
Copy link

tonimelisma commented Nov 9, 2020 •
edited

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

$ go version
go version go1.15.4 darwin/amd64

Does this issue reproduce with the latest release?

Yeah, 1.15.4 is the latest.

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/tonimelisma/Library/Caches/go-build"
GOENV="/Users/tonimelisma/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/tonimelisma/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/tonimelisma/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/tonimelisma/sdk/go1.15.4"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/tonimelisma/sdk/go1.15.4/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/tonimelisma/go/src/github.com/tonimelisma/govips-poc/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/tw/99ql4pqx5q50gr1qr1kkcjxr0000gn/T/go-build184036829=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I ran a small POC program (go run cmd/poc/main.go) which utilises the govips library (cgo bridge to libvips, a C library) to manipulate an image:
https://github.com/tonimelisma/govips-poc <- please use commit fdc047e
The program runs correctly. Optionally, at the end, I can run the vips.Shutdown() function which frees up memory etc. but as you can see, this line is commented out.

Instead, at program exit, when it's supposed to clean up, I get a stack dump.

N.B. the stack dump only happens on my macOS, it doesn't happen when running the program on my linux environment (Ubuntu Groovy).

What did you expect to see?

Successful program exit

What did you see instead?

fatal error: exitsyscall: syscall frame is no longer valid

goroutine 1 [running, locked to thread]:
runtime.throw(0x416a75a, 0x2d)
        /Users/tonimelisma/sdk/go1.15.4/src/runtime/panic.go:1116 +0x72 fp=0xc000167e70 sp=0xc000167e40 pc=0x4037952
runtime.exitsyscall()
        /Users/tonimelisma/sdk/go1.15.4/src/runtime/proc.go:3233 +0x22c fp=0xc000167ea0 sp=0xc000167e70 pc=0x406664c
runtime.cgocallbackg(0x0)
        /Users/tonimelisma/sdk/go1.15.4/src/runtime/cgocall.go:202 +0xa5 fp=0xc000167f08 sp=0xc000167ea0 pc=0x40072c5
runtime.cgocallback_gofunc(0x405620c, 0x406bee0, 0xc000167f88, 0x0)
        /Users/tonimelisma/sdk/go1.15.4/src/runtime/asm_amd64.s:794 +0x9b fp=0xc000167f28 sp=0xc000167f08 pc=0x406a5fb
runtime.asmcgocall(0x406bee0, 0xc000167f88)
        /Users/tonimelisma/sdk/go1.15.4/src/runtime/asm_amd64.s:641 +0x42 fp=0xc000167f30 sp=0xc000167f28 pc=0x406a482
runtime.libcCall(0x406bee0, 0xc000167f88, 0x416e5a8)
        /Users/tonimelisma/sdk/go1.15.4/src/runtime/sys_darwin.go:46 +0x6c fp=0xc000167f60 sp=0xc000167f30 pc=0x405620c
runtime.exit(0xc000000000)
        /Users/tonimelisma/sdk/go1.15.4/src/runtime/sys_darwin.go:256 +0x31 fp=0xc000167f88 sp=0xc000167f60 pc=0x4067a51
runtime.main()
        /Users/tonimelisma/sdk/go1.15.4/src/runtime/proc.go:226 +0x25d fp=0xc000167fe0 sp=0xc000167f88 pc=0x403a21d
runtime.goexit()
        /Users/tonimelisma/sdk/go1.15.4/src/runtime/asm_amd64.s:1374 +0x1 fp=0xc000167fe8 sp=0xc000167fe0 pc=0x406a881
exit status 2
@cherrymui
Copy link
Member

From the stack trace it looks like when Go calls exit, it calls back into Go? Is your program register anything that to be called at libc exit, and that thing calls into Go?

@tonimelisma
Copy link
Author

Does runtime.setfinalizer() count? Likely not? I've got a couple of deferred functions in main() but they're both wrapped before that as well?

@cherrymui
Copy link
Member

Does runtime.setfinalizer() count?

No. I mean, something like C atexit, maybe in the C library you referenced?

@cherrymui
Copy link
Member

A reproduce:

Go file:

package main

// void CF();
import "C"

func main() {
	C.CF()
}

//export GoF
func GoF() { println("go") }

C file:

#include <stdlib.h>

extern void GoF();

void CF() {
	atexit(GoF);
}

Running on darwin it fails with the same stack trace as above.

On (most of) other platforms we directly call syscall exit when the runtime exits. On darwin (maybe all libc platforms), maybe we should call _Exit instead of exit?

@cagedmantis cagedmantis changed the title fatal error: exitsyscall: syscall frame is no longer valid on exit of program runtime: error on exit of program on darwin fatal error: exitsyscall: syscall frame is no longer valid Nov 10, 2020
@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 10, 2020
@cagedmantis cagedmantis added this to the Backlog milestone Nov 10, 2020
@ianlancetaylor
Copy link
Contributor

I agree that we should call _exit rather than exit on Darwin.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/269378 mentions this issue: runtime: use _exit on darwin

@tonimelisma
Copy link
Author

My C library does some cleanup with an atexit() by clearing cache and releasing some file handles or stuff like that but it's a pure C library, it doesn't call any Go code. It's not even aware of Go.

The library in question is libvips 8.10.2.

@tonimelisma
Copy link
Author

@ianlancetaylor @cherrymui it's now reproducible in my CI runs:

https://github.com/davidbyttow/govips/runs/1565627149

https://github.com/davidbyttow/govips/runs/1563672162?check_suite_focus=true

Perhaps related to #24656

@tonimelisma tonimelisma mentioned this issue Dec 17, 2020
Closed
@golang golang locked and limited conversation to collaborators Dec 21, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
5 participants
@cagedmantis @ianlancetaylor @gopherbot @cherrymui @tonimelisma