runtime: race detector SIGABRT or SIGSEGV on macOS Monterey #49138
Comments
zchee
changed the title
|
cc: @cuonglm |
seankhliao
changed the title
seankhliao
added
NeedsInvestigation
|
Does it work without the race detector? It may be that the race detector .syso (in But if I was a betting man I'd blame the OS, not the syso. |
|
Try setting environment variable @zchee are you running natively on an Intel Mac or running on an ARM64 Mac under Rosetta 2? Thanks. |
|
@cherrymui I experienced the same problem on our project (and I was able to reproduce the author's original tests). I'm running natively on an Intel Mac, just upgraded to macOS 12.0.1. The env var Also yes, without the race detector everything runs fine. |
|
@TwoDCube thanks for confirming. I think this looks like a macOS bug, perhaps in their malloc implementation. |
|
Thanks @cherrymui, taking a look to see whats up! |
|
A note here that we bumped into this on Monterey and |
|
@cherrymui fixed MallocNanoZone=0 for now! |
|
@cherrymui I'll try to nvram boot-args using 0, v1 and v2. |
|
@randall77 I was try to rebuild
I didn't try yet. @cherrymui I tried |
|
I got the same (or similar) problem running on an M1 apple processor The env var |
|
We got the same error on Monterey / x86 / 1.17.1. In our case, it looks related to dns lookups, EDIT: an old issue about it: #41572 |
|
There are reports about memory leaks on Monterey: https://www.macrumors.com/2021/11/01/macos-monterey-memory-leak-user-reports/. Maybe common root cause? |
|
@cherrymui @Developer-Ecosystem-Engineering What do you have plan? We wait for Apple side fix? or, planned fix on Go side...? |
Still looking at it =) |
|
Yeah, I think we'll wait for the Apple fix. In the mean time, you can use the workaround with |
|
@cherrymui @Developer-Ecosystem-Engineering I see, Thanks for details and quickly reply. |
see golang/go#49138 hotfix until apple fix this Signed-off-by: gfanton <8671905+gfanton@users.noreply.github.com>
|
I got the similar problem running on macOS monterey.
|
|
@landryzhi That looks like a different bug. Please open a new issue. |
|
@landryzhi what version of Go are you using? We saw some similar errors with old versions of Go (which are no longer supported). (As @randall77 said, this looks different.) |
…und macOS 12 malloc reserved address On macOS 12 a new malloc implementation (nano) is used by default, and apparently it reserves address range 0x600000000000-0x600020000000, which conflicts with the address range that TSAN uses for Go. Work around the issue by changing the address range slightly. The actual change is made on LLVM at https://reviews.llvm.org/D114825 . This CL includes syso's built with the patch applied. The syso in 1.17 was identical to the syso before the equivalent fix on the main branch, so the back-ported syso is identical to the fixed syso on the main branch. Fixes #50073. Updates #49138. Change-Id: I7b367d6e042b0db39a691c71601c98e4f8728a70 Reviewed-on: https://go-review.googlesource.com/c/go/+/367916 Trust: Cherry Mui <cherryyz@google.com> Reviewed-by: Austin Clements <austin@google.com> (cherry picked from commit 5f65520) Reviewed-on: https://go-review.googlesource.com/c/go/+/370697
…und macOS 12 malloc reserved address On macOS 12 a new malloc implementation (nano) is used by default, and apparently it reserves address range 0x600000000000-0x600020000000, which conflicts with the address range that TSAN uses for Go. Work around the issue by changing the address range slightly. The actual change is made on LLVM at https://reviews.llvm.org/D114825 . This CL includes syso's built with the patch applied. The syso in 1.16 was identical to the syso before the equivalent fix on the main branch, so the back-ported syso is identical to the fixed syso on the main branch. Fixes #50072. Updates #49138. Change-Id: I7b367d6e042b0db39a691c71601c98e4f8728a70 Reviewed-on: https://go-review.googlesource.com/c/go/+/367916 Trust: Cherry Mui <cherryyz@google.com> Reviewed-by: Austin Clements <austin@google.com> (cherry picked from commit 5f65520) Reviewed-on: https://go-review.googlesource.com/c/go/+/370698
|
Change https://golang.org/cl/374314 mentions this issue: |
|
Change https://golang.org/cl/374334 mentions this issue: |
We added a workaround in runtime/race. This should not be necessary now. Updates #49138. Change-Id: Ia2010e4acc95c4ddf5f463ab2919401d893c0bac Reviewed-on: https://go-review.googlesource.com/c/go/+/374314 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
We added a workaround in runtime/race on all supported versions of Go (tip, 1.17, 1.16). This should not be necessary now. Fixes golang/go#49940. Updates golang/go#49138. Change-Id: Idd337785571fa6f429435b31d22d34bf3b346ff2 Reviewed-on: https://go-review.googlesource.com/c/build/+/374334 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
On macOS 12 a new malloc implementation (nano) is used by default, and apparently it reserves address range 0x600000000000-0x600020000000, which conflicts with the address range that TSAN uses for Go golang/go#49138 The fix is already merged in upstream, but yet not released. Change will perform OS and Golang version check and add MallocNanoZone=0 on MacOS with go17 <= 1.17.5 (I hope that 1.17.6 will include upstream fix)
Note: there is an issue with MacOS Monterey that makes need the `MallocNanoZone=0` environment variable. See: golang/go#49138 This will hopefully be fixed by Apple in an upcoming release
First, I know macOS Monterey is still beta.
But this problem started after Monterey beta 2 21A5268h (beta 1 21A5248p works), and Apple has been released RC2, so posted (share) this issue.
Note that the bellow output is in the macOS Monterey RC2 21A559, real MacBook Pro, not VM.
The issue template generated
go bugcommand with go1.17.2, but occurred in all of the Go versions.What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
go env)?go envOutputexternal info:
sw_versxcodebuild -versionWhat did you do?
Bootstrapped Go toolchain will same error, but here is reproducible setup:
Run some tests (snip passes testcase):
Copy and paste with
... 2>&1 | pbcopy.go test -v -race -count=1 -run=TestCurrent os/usergo test -v -race -count=1 -run=TestClientInsecureTransport net/httpgo test -v -race -count=1 -run=TestCgoLookupIP netgo test -v -race -count=1 -run=TestLinkerGC math/bigWhat did you expect to see?
Pass all testcase with the
-raceflag.What did you see instead?
SIGABRT or SIGSEGV.
Note that if no
-raceflag, passes at least above testcases.That might be a hint ...?
On the
release-branch.go1.4branch (I know no longer support go1.4 for darwin via https://github.com/golang/build/blob/af7dff60846ec9cb2e4cbbf7a12ad25058a8743b/env/darwin/macstadium/image-setup-notes.txt#L15):CGO_ENABLED=0 ./make.bash -a=true -d=true -v=99 -no-bannerI have all InstallAssistant.pkg for Monterey betas except RC (Apple will remove past versions in sequence, so it's no longer officially available).
Actually, I've also tested under the VM. So I can provide anything if the Go team wants assembly information, etc.
What is InstallAssistant.pkg: ttp://mrmacintosh.com/macos-12-monterey-full-installer-database-download-directly-from-apple/
The text was updated successfully, but these errors were encountered: