runtime: re-enable GOTRACEBACK=crash on macOS

[krader1961]

A recent discussion on the go-nuts mailing list had myself, and Robert Engels, confused why we didn't get core dumps when a process written in Go died from a signal such as SIGSEGV on our macOS platforms. The reason core dumps don't happen on macOS (at least on amd64) can be found in src/runtime/signal_unix.go:

//go:nosplit
func crash() {
    // OS X core dumps are linear dumps of the mapped memory,
    // from the first virtual byte to the last, with zeros in the gaps.
    // Because of the way we arrange the address space on 64-bit systems,
    // this means the OS X core file will be >128 GB and even on a zippy
    // workstation can take OS X well over an hour to write (uninterruptible).
    // Save users from making that mistake.
    if GOOS == "darwin" && GOARCH == "amd64" {
        return
    }

    dieFromSignal(_SIGABRT)
}

This should be documented. It is also unclear why the GOARCH restriction exists. Presumably the same issue affects macOS on arm64 (aka, Apple Silicon). However, I have not verified that since it requires creating a code-signed Go binary and I didn't have the necessary desire to jump through those hoops.

[Joumax14]

I agree

[ianlancetaylor]

The comment seems reasonably explanatory. At the time that the comment was written, dumping core on an amd64 running macOS generated a truly gigantic file. Doing that would serve nobody well. Perhaps macOS has changed since then.

[ianlancetaylor]

That is to say: somebody with a Mac should check whether the comment is still true. Thanks.

[krader1961]

The comment seems reasonably explanatory.

Yes, the source code comment is quite clear. My point (which I didn't make crystal clear) is that the documentation of GOTRACEBACK at https://pkg.go.dev/runtime does not include similar text. Leaving developers on macOS wondering why they aren't getting core files from their programs written in Go. Developers writing in Go shouldn't have to go spelunking through the Go source to figure this out. 😸

somebody with a Mac should check whether the comment is still true

I verified that on macOS 13.2 (Ventura) on Apple Silicon (specifically an Apple M1 Max server) it is not a problem to generate core dumps from a Go binary. The core dump is a reasonable size (comparable to any I generate from a program written in C). Note that I had to follow the directions I found at https://developer.apple.com/forums/thread/694233. Specifically, how to self-sign a Go binary so that the OS would generate a core dump from it. It appears the code signing requirements goes back to macOS 12 (Monterey), if not farther back.

I'll check whether it is still an issue on my older MacBook Pro (which I think is running macOS 12 and using the amd64 architecture). The question then becomes what to do if it isn't an issue on that relatively new macOS release but is still a problem on older macOS releases supported by Go? My vote is to remove the restriction since core dumps are disabled by default and anyone enabling core dumps should know what they are doing. It may still be a good idea to add a "dragons be here" warning to the https://pkg.go.dev/runtime text.

[krader1961]

I verified that on macOS 11.7;5 (BigSur), on an amd64 architecture, if I elide the GOOS darwin check in the crash() function I get a core dump of a reasonable size. So the current limitation on Darwin core dumps no longer seems to be necessary.

[ianlancetaylor]

Thanks for checking. Sent https://go.dev/cl/483015 to remove that oddity.

[gopherbot]

Change https://go.dev/cl/483015 mentions this issue: runtime: permit core dumps in darwin-amd64