What program are you running?

What is the complete output?

Hi @ianlancetaylor

It's a program a friend of mine wrote to simplify some of my calculation needs from the command line. I don't have the source. It just stopped working after I upgraded to High Sierra and Segmentation fault: 11 is all I get. Any way I can run with debug mode on it so I can see where it fails?

There is no separate debug mode, but you could run it under the debugger (gdb or lldb).

It's hard to understand why the program would display only "Segmentation fault: 11". Go programs install a signal handler that catches signals and reports them. Does this program use cgo at all? Otherwise the only possibility I can think of would be that the signal handler itself is receiving a signal, which obviously shouldn't happen. The debugger might show that.

I ran it using lldb and got this:
thread #1, stop reason = EXC_BAD_ACCESS (code=1, address=0xf5e656ba)
frame #0: 0x000505e9 dyldinitialPoolContent + 30761 dyldinitialPoolContent:
-> 0x505e9 <+30761>: movl 0x20(%ebp), %eax
0x505ec <+30764>: movl -0x4(%eax), %ebx
0x505ef <+30767>: movl %eax, %esp
0x505f1 <+30769>: calll 0x3f1b0 ; runtime.newstack

If it's a native go executable on Mac OS High Sierra I am assuming it uses cgo.

Can you recommend a signal handler to use and I can see if I can get any more info on this.

Cheers

The Go runtime installs its own signal handler, there isn't any meaningful way to install a different signal handler.

It would be interesting to find out whether this crash occurs before the Go signal handler is installed, or whether it occurs while executing within the Go signal handler. The Go signal handler should certainly never call runtime.newstack.

@ianlancetaylor Hello! I don't have a computer running High Sierra right now, but I did receive two reports of a Go program I help maintain failing with this same symptom on High Sierra: awslabs/amazon-ecr-credential-helper#69 and awslabs/amazon-ecr-credential-helper#70. You might be able to use https://github.com/awslabs/amazon-ecr-credential-helper to help debug.

@samuelkarp can you provide more details? I don't know what your program does, how to use it, and what environment it needs. I can't help debugging if I can't reproduce the bug. Can you work with your reporters to provide instructions for a reproducible environment that shows the bug?

I had the same thing happen to me. FWIW, it was tj/robo built from source using go get back on 10.12. I doubt this is of much use, as I don't remember the exact Go version it was built with since it was a while ago... maybe 1.7.

@rasky From the reports I received, I think it's sufficient to compile it on an older macOS release (or cross-compile from Linux) and then attempt to invoke the program. If you invoke it without arguments or any input to stdin, it should just print out a help message and exit with exit code 1.

Re-installing Go from package at https://golang.org/dl/ did the trick for me.

Still an issue for me. No progress on my end.

Ok,I also meet this question and it was resolved!
I install the latest OS Mac OS High Sierra, and the revel can not work. It report error segmentation fault.
I reinstall the go by the follow command brew reinstall go.
After type the above command, my golang was upgrade to 1.9.2.
And then, rebuild revel command. go build github.com/revel/cmd/revel

Thanks for the reports, everyone, but we need more information to debug this.

It sounds like everyone has been able to get their binaries working by recompiling with a more recent toolchain (e.g., 1.9). That might mean there's nothing we can really do about this, but I'd like to confirm that.

Has anyone experienced this crash with a binary that was definitely built with 1.9 (or master)?

For anyone who still has a crashing binary around, I'd like to know what Go version it was compiled with. To find out, run go get rsc.io/goversion and run goversion <binary>.

I'm trying to get goversion installed on Mac but can't seem to find where it is installed after executing your command. Eager to help.

Thank you for that. The app that is not working for me was compiled with Go v1.6.2. I'm assuming I have to contact the developer of this program to recompile the binary with a newer version of Go? Can we safely say that Go v1.6.2 is not supported on High Sierra?

Thanks Dave :-)

Thanks! For reference, the issue about improved forward-compatibility on macOS is #17490.