Go: runtime: bsdthread_register fatal error (CylancePROTECT)

Created on 2 Dec 2016  Â·  51Comments  Â·  Source: golang/go

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

go version go1.8beta1

What operating system and processor architecture are you using (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, ...)

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.

FrozenDueToAge NeedsInvestigation

Most helpful comment

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

All 51 comments

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

derekperkins picture derekperkins  Â·  180Comments

ianlancetaylor picture ianlancetaylor  Â·  519Comments

chai2010 picture chai2010  Â·  216Comments

ghost picture ghost  Â·  222Comments

networkimprov picture networkimprov  Â·  194Comments