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.

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

runtime: bsdthread_register fatal error (CylancePROTECT) #18171

Closed
ksaldana1 opened this issue Dec 2, 2016 · 51 comments

Comments

Projects
None yet
@ksaldana1
Copy link

commented Dec 2, 2016

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

go version go1.8beta1

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

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, ...)

What did you expect to see?

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.

@minux minux added this to the Go1.8 milestone Dec 3, 2016

@minux

This comment has been minimized.

Copy link
Member

commented Dec 3, 2016

@dhananjay92

This comment has been minimized.

Copy link
Member

commented Dec 5, 2016

@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?

@minux

This comment has been minimized.

Copy link
Member

commented Dec 5, 2016

@bradfitz bradfitz changed the title Go 1.8beta1 - fatal error: runtime: bsdthread_register error runtime: bsdthread_register fatal error Dec 5, 2016

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 6, 2016

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.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 6, 2016

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.

@josharian

This comment has been minimized.

Copy link
Contributor

commented Dec 6, 2016

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.

@minux

This comment has been minimized.

Copy link
Member

commented Dec 7, 2016

@DemiMarie

This comment has been minimized.

Copy link

commented Dec 12, 2016

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?

@minux

This comment has been minimized.

Copy link
Member

commented Dec 12, 2016

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2016

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.

@rsc rsc modified the milestones: Go1.9Early, Go1.8 Dec 13, 2016

@jasdel

This comment has been minimized.

Copy link
Contributor

commented Jan 17, 2017

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.

@jasdel

This comment has been minimized.

Copy link
Contributor

commented Jan 17, 2017

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.

@polds

This comment has been minimized.

Copy link

commented Feb 20, 2017

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.

@DavidHuie

This comment has been minimized.

Copy link

commented Feb 21, 2017

I'm also running into the issue. I have Cylance installed as well.

@roblally

This comment has been minimized.

Copy link

commented Feb 21, 2017

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

@alotofnoodles

This comment has been minimized.

Copy link

commented Feb 22, 2017

I can confirm that I am having the same error on macOS Sierra, Go 1.8, running Cylance protect.

@alotofnoodles

This comment has been minimized.

Copy link

commented Feb 23, 2017

I managed to get around this problem by asking the IT support to change the Cylance policy to (MAC - BG).

@jamiseichenauer

This comment has been minimized.

Copy link

commented Mar 7, 2017

You can try to have your Cylance administrator add the following Memory Protection exclusions:
https://support.cylance.com/hc/en-us/articles/115004085328

@fooeyandnuts

This comment has been minimized.

Copy link

commented Mar 8, 2017

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

@rsc

This comment has been minimized.

Copy link
Contributor

commented Mar 8, 2017

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).

@bradfitz

This comment has been minimized.

Copy link
Member

commented Mar 8, 2017

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.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Mar 8, 2017

It's not just antivirus, though. It's also DTrace. See #17819, merged (I think incorrectly) into #17490.

@rsc

This comment has been minimized.

Copy link
Contributor

commented May 24, 2017

Perhaps someone can followup with Cylance?

@rsc rsc modified the milestones: Go1.10, Go1.9Maybe May 24, 2017

@polds

This comment has been minimized.

Copy link

commented May 24, 2017

@rsc We have a contact with Cylance, anything in particular you'd recommend reaching out to them about?

@rsc rsc closed this May 24, 2017

@rsc rsc reopened this May 24, 2017

@rsc

This comment has been minimized.

Copy link
Contributor

commented May 24, 2017

@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.

@polds

This comment has been minimized.

Copy link

commented May 24, 2017

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
@ccampo133

This comment has been minimized.

Copy link

commented May 24, 2017

@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.

@rsc

This comment has been minimized.

Copy link
Contributor

commented May 25, 2017

@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

@j-mroz

This comment has been minimized.

Copy link

commented May 31, 2017

By the way, gofmt works if I run it via lldb for some reason, doesn't crash ...

@j-mroz

This comment has been minimized.

Copy link

commented May 31, 2017

I've done a git bisect on golang repository using all.bash script to check for the issue

276803d is the first bad commit
commit 276803d
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 <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

:040000 040000 621194da05c8a090f3aadb7b36a5d2769384f20a 75b4f6cac52c869353962f88f72a568a86348573 M src

@polds

This comment has been minimized.

Copy link

commented May 31, 2017

So, my contact no longer works at Cylance, I'm going through alternative "slow channels" but not having high hopes.

@DemiMarie

This comment has been minimized.

Copy link

commented May 31, 2017

@j-mroz

This comment has been minimized.

Copy link

commented Jun 1, 2017

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 4aa5d2e.

Why on earth that would change anything?

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jun 5, 2017

@DemiMarie, I agree we might want to do that in the long term, but it's tricky to bootstrap (see #18171 (comment) and #18171 (comment) 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.

@gopherbot

This comment has been minimized.

Copy link

commented Jun 5, 2017

CL https://golang.org/cl/44870 mentions this issue.

@j-mroz

This comment has been minimized.

Copy link

commented Jun 5, 2017

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.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jun 5, 2017

@abscondment

This comment has been minimized.

Copy link

commented Jun 19, 2017

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 🎊

@bru7us

This comment has been minimized.

Copy link

commented Jun 28, 2017

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.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jun 28, 2017

Thanks so much @ascondment, @bru7us, and the engineers at Cylance who got this fixed.

@rsc rsc closed this Jun 28, 2017

@nilator83

This comment has been minimized.

Copy link

commented Jun 30, 2017

@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?

@landonix

This comment has been minimized.

Copy link

commented Jul 12, 2017

@nilator83 1450 was released on June 20th, you may need to ask your Cylance admin to enable it for your zone

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.