go version)?go version go1.8beta1
go env)?```GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/kevin.saldana/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
uname -prsv
Darwin 14.5.0 Darwin Kernel Version 14.5.0: Mon Aug 29 21:14:16 PDT 2016; root:xnu-2782.50.6~1/RELEASE_X86_64 i386
### What did you do?
Any call to go build/tools fails with
```
fatal error: runtime: bsdthread_register error
runtime stack:
runtime.throw(0x16b2b8c, 0x21)
/usr/local/go/src/runtime/panic.go:596 +0x95 fp=0x7fff5fbff180 sp=0x7fff5fbff160
runtime.goenvs()
/usr/local/go/src/runtime/os_darwin.go:108 +0xa0 fp=0x7fff5fbff1b0 sp=0x7fff5fbff180
runtime.schedinit()
/usr/local/go/src/runtime/proc.go:476 +0xa1 fp=0x7fff5fbff1f0 sp=0x7fff5fbff1b0
runtime.rt0_go(0x7fff5fbff220, 0x11, 0x7fff5fbff220, 0x0, 0x11, 0x7fff5fbff490, 0x7fff5fbff4bc, 0x7fff5fbff4bf, 0x7fff5fbff549, 0x7fff5fbff553, ...)
Working builds.
I have gone through all threads related to this error and have tried their solutions (disabling anti-virus, messing with DYLD environment variables, adding -ldflags -linkmode=external to build) and am still running into this issue.
Note, I am running an old version of OSX -- Yosemite v10.10.5.
I have tried both building from source and using the installer. Same effect either way.
Downgrading to 1.7.4 does not run into this error.
It will be helpful to know what does bsdthread_register return.
Could you please apply this patch to Go 1.8beta source code and
post what does the new println say?
https://gist.github.com/minux/ef054728f5f9b8e3685b88f5c88d1ad3
(I don't post the patch inline because github and/or Gmail will
reformat the message and make it harder to apply the patch.)
Thanks.
@minux I think we should just include the return value in error message permanently. That would make it easier to debug in future.
i.e.
if r := bsdthread_register(); r != 0 {
...
throw(fmt.Sprintf("runtime: bsdthread_register error(%d)", r))
}
WDYT?
Yeah, we can do that, but I'm still interested in this particular case
because this is obviously system dependent (so far we only got
one such issue, so it's not widespread....)
Is the go command binary itself crashing? We have built the go binary for 1.8 beta 1 on Macs without problems. I'm wondering what is different about your system.
It may work to try
GO_LDFLAGS=-linkmode=external ./all.bash
but I don't know that would be necessary. I wonder if there's something on your system intercepting process execution and doing an implicit DYLD insertion.
FWIW, I can generate this panic 100% of the time (on macOS Sierra) using both 1.7.4 and tip by running an executable under dtruss:
$ go build -o hw17 ~/hello.go
$ sudo dtruss ./hw17
Password:
SYSCALL(args) = return
fatal error: runtime: bsdthread_register error
runtime stack:
runtime.throw(0xa79ad, 0x21)
/Users/josh/go/1.7/src/runtime/panic.go:566 +0x95 fp=0x7fff5fbffb80 sp=0x7fff5fbffb60
runtime.goenvs()
/Users/josh/go/1.7/src/runtime/os_darwin.go:88 +0xa0 fp=0x7fff5fbffbb0 sp=0x7fff5fbffb80
runtime.schedinit()
/Users/josh/go/1.7/src/runtime/proc.go:450 +0x9c fp=0x7fff5fbffbf0 sp=0x7fff5fbffbb0
runtime.rt0_go(0x7fff5fbffc28, 0x1, 0x7fff5fbffc28, 0x0, 0x0, 0x1, 0x7fff5fbffd28, 0x0, 0x7fff5fbffd2f, 0x7fff5fbffd3d, ...)
/Users/josh/go/1.7/src/runtime/asm_amd64.s:145 +0x14f fp=0x7fff5fbffbf8 sp=0x7fff5fbffbf0
thread_selfid(0x0, 0x0, 0x0) = 672106 0
open(".\0", 0x0, 0x1) = 3 0
... elided ...
GO_LDFLAGS=-linkmode=external does not fix it.
dtrace will insert libSystem.dylib into the process, so using dtrace on
non-cgo Go binaries will result in a crash. This is known.
What does bsdthread_register even _do_? I cannot find _any_ documentation for it other than it being an undocumented by Apple. Every other reference to it is in the context of Go. Why is it a fatal error if it fails?
Register a thread creation callback function to the kernel.
A process can only register one. When cgo is not used (internal linking),
Go doesn't pthread_create to create threads, and registers its own
thread creation callback function.
See https://golang.org/src/runtime/sys_darwin_amd64.s for details.
We still don't know why @ksaldana1's system is force-inserting libSystem.dylib into ordinary process execution. Maybe we can make all binaries expect libSystem.dylib, but I think it's too late for Go 1.8.
Updating to go 1.8rc1 I've noticed this issue as well on OSX 10.11.6. Reverting back to 1.7.4 does not reproduce the issue. I did not experienced the issue with 1.8beta1, but I did recently have a antivirus software installed on my system within the past few days. Not sure if that is related.
I rebuilt Go from source on both tip and go1.8rc1 tag, and doing so lets me build and run Go source. Only using the pre-built package on golang.org/dl for 1.8 do I experience the issue.
Just thought I'd chime in, just ran into this as well in the upgrade to 1.8. I was running CylanceProtect and it would throw the same errors. Strangely 1.7.x had no issues.
I'm also running into the issue. I have Cylance installed as well.
I also have the same problem and I have Cylance installed.
In case the information is useful:
OSX El Capitan
Go 1.8, installed via brew
CylanceProtect
I can confirm that I am having the same error on macOS Sierra, Go 1.8, running Cylance protect.
I managed to get around this problem by asking the IT support to change the Cylance policy to (MAC - BG).
You can try to have your Cylance administrator add the following Memory Protection exclusions:
https://support.cylance.com/hc/en-us/articles/115004085328
If you need to pass along to your Cylance administrators, this article indicates the directories that need to be excluded to work around Go 1.8 fatal errors.
https://support.cylance.com/hc/en-us/articles/115004085328
I'm curious why this started in Go 1.8. The fact that @jasdel rebuilding from source doesn't have the problem is also interesting, although that didn't help @ksaldana1. I wonder if it means our build has changed in some way.
At a glance, I can't see anything different about the Go 1.8 binaries vs the Go 1.7.5 binaries. bin/go should be using cgo in both versions, which should make it not call bsdthread_register at all. Perhaps @jamiseichenauer was over-conservative and the go command does not need to be on the whitelist.
tool/compile and tool/link don't use cgo (because they don't have network code in them), and they do try to call bsdthread_register.
We can close this issue forever by making all Go binaries built for OS X implicitly import "runtime/cgo" (when CGO_ENABLED=1). Then Go will always use libpthread for thread creation and not call bsdthread_register (again assuming cgo is enabled).
We can close this issue forever by making all Go binaries built for OS X implicitly import "runtime/cgo" (when CGO_ENABLED=1). Then Go will always use libpthread for thread creation and not call bsdthread_register (again assuming cgo is enabled).
I don't want to play the game of trying to make antivirus happy. Nobody ever seems to win that game.
It's not just antivirus, though. It's also DTrace. See #17819, merged (I think incorrectly) into #17490.
Can confirm that this happens with Go 1.8 on OS X El Cap 10.11.6 running Cylance 1.2.1418.609.
Similar to @ccampo133, I can also confirm that this happens with both Go 1.8 and Go 1.8.1 on OS X El Cap 10.11.6 running Cylance 1.2.1418.609, but does not happen with Go 1.7.5.
Confirming works on 1.7.4 & 1.7.5, fails on 1.8 and 1.8.1
CylancePROTECT 1.2.1400.524 on El Capitan 10.11.6
I started to look into this, but compiling runtime/cgo requires invoking the cgo binary, which would have to be linked with runtime/cgo in order to get past Cylance, which is a cycle. The cycle can be broken by having a special bootstrap cgo binary that isn't linked using cgo code, but that starts to get a bit complex. Leaving for later.
Confirming as well:
Working with Go v1.7.5, failing with Go v1.8.1. Haven't tried other versions.
I have CylancePROTECT Version 2.0.1420.528.
Mac OS X Sierra 10.12.4
Figured out how to temporarily work around this, everytime i start my computer i run:
sudo launchctl unload /Library/launchdaemons/com.cylance.agent_service.plist
Same problem here.
Same problem. 1.7.6 works. 1.8 or 1.8.1 does not.
We don't know why this is happening, nor why it started with Go 1.8. It's very likely not going to be fixed for Go 1.9. Sorry.
Perhaps someone can followup with Cylance?
@rsc We have a contact with Cylance, anything in particular you'd recommend reaching out to them about?
@polds, thanks for the offer. Before we ping Cylance, can people having this problem try the following? I've attached go-issue-18171.zip with six binaries, three from Go 1.7.6 and three from Go 1.8.2.
$ unzip -l go-issue-18171.zip
Archive: go-issue-18171.zip
Length Date Time Name
--------- ---------- ----- ----
0 05-24-2017 10:19 go-issue-18171/
9884220 05-24-2017 10:19 go-issue-18171/go1.7.6
9985940 05-24-2017 10:19 go-issue-18171/go1.8.2
15065500 05-24-2017 10:18 go-issue-18171/godoc1.7.6
15129860 05-24-2017 10:18 go-issue-18171/godoc1.8.2
2976976 05-24-2017 10:18 go-issue-18171/gofmt1.7.6
3320448 05-24-2017 10:18 go-issue-18171/gofmt1.8.2
--------- -------
56362944 7 files
@andredasilvapinto, @j-mroz, @polds, anyone else having problems, can you download the zip file and then run:
unzip go-issue-18171.zip
cd go-issue-18171
./go1.7.6 -help
./godoc1.7.6 -help
./gofmt1.7.6 -help
./go1.8.2 -help
./godoc1.8.2 -help
./gofmt1.8.2 -help
and post the resulting shell transcript? On my non-Cylanced system, I just get help messages. But the expectation is that under Cylance some of these binaries will fail. Specifically, I expect gofmt1.8.2 to fail but not any of the others. Confirming or disproving that assumption would be useful for asking good questions of Cylance.
Thanks.
So of interesting note, I just installed Cylance on a VM (had to disable it since it's been messing with Go) I did not see the errors in Cylance 1.0.x. When I upgraded to Version 2.0.x it started throwing those errors.
@rsc Here is the output of those commands, successful results stripped (you were right about gofmt failing):
Peters-Mac:go-issue-18171 peter$ ./go1.7.6 -help
# success
Peters-Mac:go-issue-18171 peter$ ./godoc1.7.6 -help
# success
Peters-Mac:go-issue-18171 peter$ ./gofmt1.7.6 -help
# success
Peters-Mac:go-issue-18171 peter$ ./go1.8.2 -help
# success
Peters-Mac:go-issue-18171 peter$ ./godoc1.8.2 -help
# success
Peters-Mac:go-issue-18171 peter$ ./gofmt1.8.2 -help
fatal error: runtime: bsdthread_register error
runtime stack:
runtime.throw(0x1177bef, 0x21)
/usr/local/go/src/runtime/panic.go:596 +0x95 fp=0x7fff5fbffb10 sp=0x7fff5fbffaf0
runtime.goenvs()
/usr/local/go/src/runtime/os_darwin.go:108 +0xa0 fp=0x7fff5fbffb40 sp=0x7fff5fbffb10
runtime.schedinit()
/usr/local/go/src/runtime/proc.go:486 +0xa1 fp=0x7fff5fbffb80 sp=0x7fff5fbffb40
runtime.rt0_go(0x7fff5fbffbb8, 0x2, 0x7fff5fbffbb8, 0x0, 0x0, 0x2, 0x7fff5fbffcd0, 0x7fff5fbffcdd, 0x0, 0x7fff5fbffce3, ...)
/usr/local/go/src/runtime/asm_amd64.s:158 +0x183 fp=0x7fff5fbffb88 sp=0x7fff5fbffb80
@rsc Here is my output (OS X El Cap 10.11.6 with Cylance 1.2.1418.609):
$ ./go1.7.6 -help
Go is a tool for managing Go source code.
Usage:
go command [arguments]
The commands are:
build compile packages and dependencies
clean remove object files
doc show documentation for package or symbol
env print Go environment information
fix run go tool fix on packages
fmt run gofmt on package sources
generate generate Go files by processing source
get download and install packages and dependencies
install compile and install packages and dependencies
list list packages
run compile and run Go program
test test packages
tool run specified go tool
version print Go version
vet run go tool vet on packages
Use "go help [command]" for more information about a command.
Additional help topics:
c calling between Go and C
buildmode description of build modes
filetype file types
gopath GOPATH environment variable
environment environment variables
importpath import path syntax
packages description of package lists
testflag description of testing flags
testfunc description of testing functions
Use "go help [topic]" for more information about that topic.
$ ./godoc1.7.6 -help
usage: godoc package [name ...]
godoc -http=:6060
-analysis string
comma-separated list of analyses to perform (supported: type, pointer). See http://golang.org/lib/godoc/analysis/help.html
-ex
show examples in command line mode
-goroot string
Go root directory (default "/usr/local/go")
-html
print HTML in command-line mode
-http string
HTTP service address (e.g., ':6060')
-httptest.serve string
if non-empty, httptest.NewServer serves on this address and blocks
-index
enable search index
-index_files string
glob pattern specifying index files; if not empty, the index is read from these files in sorted order
-index_interval duration
interval of indexing; 0 for default (5m), negative to only index once at startup
-index_throttle float
index throttle value; 0.0 = no time allocated, 1.0 = full throttle (default 0.75)
-links
link identifiers to their declarations (default true)
-maxresults int
maximum number of full text search results shown (default 10000)
-notes string
regular expression matching note markers to show (default "BUG")
-play
enable playground in web interface
-q arguments are considered search queries
-server string
webserver address for command line searches
-src
print (exported) source in command-line mode
-tabwidth int
tab width (default 4)
-templates string
directory containing alternate template files
-timestamps
show timestamps with directory listings
-url string
print HTML for named URL
-v verbose mode
-write_index
write index to a file; the file name must be specified with -index_files
-zip string
zip file providing the file system to serve; disabled if empty
$ ./gofmt1.7.6 -help
usage: gofmt [flags] [path ...]
-cpuprofile string
write cpu profile to this file
-d display diffs instead of rewriting files
-e report all errors (not just the first 10 on different lines)
-l list files whose formatting differs from gofmt's
-r string
rewrite rule (e.g., 'a[b:len(a)] -> a[b:]')
-s simplify code
-w write result to (source) file instead of stdout
$ ./go1.8.2 -help
Go is a tool for managing Go source code.
Usage:
go command [arguments]
The commands are:
build compile packages and dependencies
clean remove object files
doc show documentation for package or symbol
env print Go environment information
bug start a bug report
fix run go tool fix on packages
fmt run gofmt on package sources
generate generate Go files by processing source
get download and install packages and dependencies
install compile and install packages and dependencies
list list packages
run compile and run Go program
test test packages
tool run specified go tool
version print Go version
vet run go tool vet on packages
Use "go help [command]" for more information about a command.
Additional help topics:
c calling between Go and C
buildmode description of build modes
filetype file types
gopath GOPATH environment variable
environment environment variables
importpath import path syntax
packages description of package lists
testflag description of testing flags
testfunc description of testing functions
Use "go help [topic]" for more information about that topic.
$ ./godoc1.8.2 -help
usage: godoc package [name ...]
godoc -http=:6060
-analysis string
comma-separated list of analyses to perform (supported: type, pointer). See http://golang.org/lib/godoc/analysis/help.html
-ex
show examples in command line mode
-goroot string
Go root directory (default "/usr/local/go")
-html
print HTML in command-line mode
-http string
HTTP service address (e.g., ':6060')
-httptest.serve string
if non-empty, httptest.NewServer serves on this address and blocks
-index
enable search index
-index_files string
glob pattern specifying index files; if not empty, the index is read from these files in sorted order
-index_interval duration
interval of indexing; 0 for default (5m), negative to only index once at startup
-index_throttle float
index throttle value; 0.0 = no time allocated, 1.0 = full throttle (default 0.75)
-links
link identifiers to their declarations (default true)
-maxresults int
maximum number of full text search results shown (default 10000)
-notes string
regular expression matching note markers to show (default "BUG")
-play
enable playground in web interface
-q arguments are considered search queries
-server string
webserver address for command line searches
-src
print (exported) source in command-line mode
-tabwidth int
tab width (default 4)
-templates string
load templates/JS/CSS from disk in this directory
-timestamps
show timestamps with directory listings
-url string
print HTML for named URL
-v verbose mode
-write_index
write index to a file; the file name must be specified with -index_files
-zip string
zip file providing the file system to serve; disabled if empty
$./gofmt1.8.2 -help
fatal error: runtime: bsdthread_register error
runtime stack:
runtime.throw(0x1177bef, 0x21)
/usr/local/go/src/runtime/panic.go:596 +0x95 fp=0x7fff5fbff150 sp=0x7fff5fbff130
runtime.goenvs()
/usr/local/go/src/runtime/os_darwin.go:108 +0xa0 fp=0x7fff5fbff180 sp=0x7fff5fbff150
runtime.schedinit()
/usr/local/go/src/runtime/proc.go:486 +0xa1 fp=0x7fff5fbff1c0 sp=0x7fff5fbff180
runtime.rt0_go(0x7fff5fbff1f0, 0x2, 0x7fff5fbff1f0, 0x0, 0x2, 0x7fff5fbff4c0, 0x7fff5fbff4cd, 0x0, 0x7fff5fbff4d3, 0x7fff5fbff4e3, ...)
/usr/local/go/src/runtime/asm_amd64.s:158 +0x183 fp=0x7fff5fbff1c8 sp=0x7fff5fbff1c0
Appears that ./gofmt1.8.2 -help is the only command that fails.
@polds, thanks, OK, so then here's my question for Cylance.
As background, on the Mac, C programs using threads use libSystem.dylib to interact with the operating system to manage those threads. Go programs that call out to C libraries do the same. But Go programs that don't call out to C libraries do everything themselves, to avoid any dependencies on C when not needed. Using networking on a Mac means calling a C library, so on a Mac it's the basic file I/O-only Go programs that don't use the usual C threads. This has been true from Go 1.0 and before.
As more background, we also know from experience that some Mac programs force dynamic loading of libraries ahead of ordinary program start, including libSystem.dylib. For example if you run under dtruss, you can't avoid having libSystem.dylib. If libSystem.dylib is forced into a Go binary expecting to manage threads itself, the two do not get along: Go's bsdthread_register system call fails, causing output like the errors above. We've also seen this with interposition software that sets the DYLD_INSERT_LIBRARIES environment variable.
Now, about Cylance. The failing gofmt binary from Go 1.8.2 (gofmt1.8.2 in go-issue-18171.zip) is behaving for all the world like Cylance is doing some kind of early dynamic library loading that is registering for creating threads before Go can. The question is why gofmt from Go 1.7.6 (gofmt1.7.6 in the same zip file) works fine. On the Go side, nothing about this arrangement changed from Go 1.7 to Go 1.8. Does Cylance somehow know about or detect Go binaries and avoid doing the interposition, and perhaps the detector recognizes Go 1.7 binaries but not Go 1.8 binaries? Is there any advice Cylance would give us on what we can do to make our newer binaries be treated like the Go 1.7 binaries are treated?
An alternative long-term fix would be to use libSystem.dylib even for non-C-using Go binaries, but that's technically quite difficult for us and wouldn't be something we could do retroactively to Go 1.8 or even the upcoming Go 1.9.
Thanks very much.
Russ
By the way, gofmt works if I run it via lldb for some reason, doesn't crash ...
I've done a git bisect on golang repository using all.bash script to check for the issue
276803d6111b46c66956c99d982d70f23820ba5d is the first bad commit
commit 276803d6111b46c66956c99d982d70f23820ba5d
Author: David Crawshaw crawshaw@golang.org
Date: Mon Sep 5 23:29:16 2016 -0400
cmd/link: introduce a rel.ro segment
When internally linking with using rel.ro sections, this segment covers
the sections. To do this, move to other read-only sections, SELFROSECT
and SMACHOPLT, out of the way.
Part of adding PIE internal linking on linux/amd64.
Change-Id: I4fb3d180e92f7e801789ab89864010faf5a2cb6d
Reviewed-on: https://go-review.googlesource.com/28538
Run-TryBot: David Crawshaw <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Ian Lance Taylor <[email protected]>
:040000 040000 621194da05c8a090f3aadb7b36a5d2769384f20a 75b4f6cac52c869353962f88f72a568a86348573 M src
So, my contact no longer works at Cylance, I'm going through alternative "slow channels" but not having high hopes.
I wonder if Go should just use libSystem.dylib always on macOS. I would
imagine that doing anything else is not supported by Apple.
On May 31, 2017 11:52 AM, "Peter Olds" notifications@github.com wrote:
So, my contact no longer works at Cylance, I'm going through alternative
"slow channels" but not having high hopes.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/18171#issuecomment-305231176, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGGWBzhOBjLmUfjplknF4Yt1THhjUlOLks5r_YytgaJpZM4LDD37
.
Moving sections SELFROSECT and SMACHOPLT to their old position after the SPCLNTAB fixes the issue with bsdthread_register.
files changed: cmd/link/internal/ld/symkind.go, src/cmd/link/internal/ld/data.go.
But not all test have passed, for some reason that I haven't checked net/http test failed. I've used latest commit form master that I had as a base 4aa5d2eede522567b183f11fd201e5d257fe652a.
Why on earth that would change anything?
@DemiMarie, I agree we might want to do that in the long term, but it's tricky to bootstrap (see https://github.com/golang/go/issues/18171#issuecomment-285098816 and https://github.com/golang/go/issues/18171#issuecomment-293366609 above).
@j-mroz, thanks very much for finding that. Can you send a CL, even if it breaks net/http? Maybe someone else can figure out what's wrong with net/http. Also network tests on macOS are flaky under some configurations, apparently due to problems with the macOS network stack. So your change might be fine.
Thanks everyone.
CL https://golang.org/cl/44870 mentions this issue.
I've also experienced net and log/syslog tests failure - "signal: broken pipe", but then it all worked. Seems to be random, and not reproducible all the time.
Anyway, I've posted a CL as you suggested .
I just reverted parts of the original commit but I do not know if it is full fix or does it introduces a regression. Hope that it helps you solve the issue.
CC @crawshaw
One of our contacts at Cylance has been working on this issue, and has targeted the 1450 release for resolving it.
I just got added the Early Adopter release for the 1450...
Preliminary results: this issue hasn't appeared when running 1.8.3 with CylancePROTECT 2.0.1.1450.505 🎊
FWIW: El Capitan and go 1.8.3 with CylancePROTECT (now at 2.0.1450.506) not producing the error where this same machine was producing it before a Cylance update.
Thanks so much @ascondment, @bru7us, and the engineers at Cylance who got this fixed.
@rsc @abscondment @bru7us I am experiencing the same issue but do not have the update mentioned for cylance.
Mac OSX Sierra 10.12.5
Cylance Agent Version 2.0.1440.541 (No other available update to push from the console)
Go Version: go1.8.3 darwin/amd64
Do you know when this update will get pushed to Sierra?
@nilator83 1450 was released on June 20th, you may need to ask your Cylance admin to enable it for your zone
Most helpful comment
Figured out how to temporarily work around this, everytime i start my computer i run: