Downloaded Terraform executables and get this when running on a Mac...
> terraform
fatal error: runtime: bsdthread_register error
runtime stack:
runtime.throw(0x638b35)
/opt/go/src/pkg/runtime/panic.c:520 +0x69
runtime.goenvs()
/opt/go/src/pkg/runtime/os_darwin.c:88 +0x62
runtime.schedinit()
/opt/go/src/pkg/runtime/proc.c:164 +0x76
_rt0_go()
/opt/go/src/pkg/runtime/asm_amd64.s:91 +0x114
Any ideas? Need any additional information?
This is definitely some Go error, since it isn't even reaching Terraform. Can you report this upstream to the Go project? I would but they'll probably want to know some things about your system...
Hello,
I am seeing this with the latest version of terraform downloaded today.. 0.8.8 - on MacOS 10.12.4 Beta (16E175b)
$ terraform
fatal error: runtime: bsdthread_register error
runtime stack:
runtime.throw(0x4cbad8a, 0x21)
/opt/go/src/runtime/panic.go:596 +0x95 fp=0x7fff5fbff340 sp=0x7fff5fbff320
runtime.goenvs()
/opt/go/src/runtime/os_darwin.go:108 +0xa0 fp=0x7fff5fbff370 sp=0x7fff5fbff340
runtime.schedinit()
/opt/go/src/runtime/proc.go:486 +0xa1 fp=0x7fff5fbff3b0 sp=0x7fff5fbff370
runtime.rt0_go(0x7fff5fbff3e0, 0x1, 0x7fff5fbff3e0, 0x0, 0x1, 0x7fff5fbff570, 0x0, 0x7fff5fbff57a, 0x7fff5fbff597, 0x83026b0, ...)
/opt/go/src/runtime/asm_amd64.s:158 +0x183 fp=0x7fff5fbff3b8 sp=0x7fff5fbff3b0
0.8.7 does not have this problem.
I've googled around and it looks like the primary cause of this (on macOS) is other software interfering and it is usually anti-virus/firewall. All of us on the Terraform team use macOS and we don't see this issue and Googling points to this 100% of the time being a system environment issue.
A Mac user (El Capitan) user here can confirm the same issue. I'd hoped to see more than a "hey it works for me" response.
The issue is that go (1.8) is utilizing a BSD syscall directly (Mac kernel is screwy). I believe it is trying to initialize BSD threading and is confused because it is already initialized. It usually isn't an issue, because most software uses the APIs rather than doing direct kernel calls. So what is occurring is that MemDef is being defined again after the thread already exists.
On our end, they've excluded the program from our policies but thats about it..
(I work at an AV vendor had team look at dump)
I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.