runtime: race detector on ARM64 doesn't fully work #28848
Comments
|
Any thoughts to resolve this issue? I'm willing to implement that. |
|
Change https://golang.org/cl/149967 mentions this issue: |
|
Change https://golang.org/cl/150457 mentions this issue: |
|
I send CL https://go-review.googlesource.com/c/go/+/150457 to add explicit arg maps. Now the race detector tests in all.bash pass. Many tests in race.bash also pass, but some failed with |
|
If it's not an OOM, the second most common cause for this is getting a In general you will see this kind of thing if you get a fatal signal such as |
In race mode, these functions are defined and declared in different packages, which therefore don't have implicit arg maps. When they are defer'd, and the stack needs to move, the runtime fails with missing stack maps. This CL adds arg maps (FUNCDATA) to them. Updates #28848 Change-Id: I0271563b7e78e7797ce2990c303dced957efaa86 Reviewed-on: https://go-review.googlesource.com/c/150457 Run-TryBot: Cherry Zhang <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Brad Fitzpatrick <[email protected]>
|
@cherrymui I ran all.bash and race.bash at CL150457 on my arm64 box (not qemu, 6GB RAM), all tests passed. |
|
Thanks @ianlancetaylor for the information. The builder machine doesn't seem to have gdb installed, so I couldn't easily find out whether it received a Thanks @mengzhuo for sharing your results. How many CPU cores are there on your machine? I think we still want to find out why it fails on the builder. One thing I noticed is that the builder has 96 cores, so when running the tests it may launch quite a number of processes/threads. This might lead to high memory consumption? About OOMing, I tried to run an individual test that is likely to fail ( It seems odd to me that it keeps consuming swap while there is still a good amount of free memory. Maybe there is some memory limit? As a comparison, running the same test in non-race mode doesn't use much swap. |
In race mode, these functions are defined and declared in different packages, which therefore don't have implicit arg maps. When they are defer'd, and the stack needs to move, the runtime fails with missing stack maps. This CL adds arg maps (FUNCDATA) to them. Updates #28848 Change-Id: I0271563b7e78e7797ce2990c303dced957efaa86 Reviewed-on: https://go-review.googlesource.com/c/150457 Run-TryBot: Cherry Zhang <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Brad Fitzpatrick <[email protected]>
|
@cherrymui I also ran race.bash on 3 machines with different configuration, all the tests passed. I didn't observe obvious consumption of swap space during the test on machin A and B |
CL 138675 added the race detector support on Linux/ARM64, but it didn't enable the race detector tests in cmd/dist (therefore in all.bash). Enable them. Updates #28848 Change-Id: I4306dad2fb4167021d568436076b9f535d7f6e07 Reviewed-on: https://go-review.googlesource.com/c/149967 Run-TryBot: Cherry Zhang <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]>
|
@randall77 submitted: "runtime: save g register during arm64 race detector callbacks" |
|
I run race.bash on the linux-arm64-aws builder and on a ARM64 macOS machine and they both work well. I think we can close this. |
What version of Go are you using (
go version)?tip (6797b32)
Does this issue reproduce with the latest release?
No.
What operating system and processor architecture are you using (
go env)?linux/arm64
What did you do?
CL https://go-review.googlesource.com/c/go/+/138675/ adds race detector support to Linux/ARM64. But when I try to enable the race detector tests in cmd/dist (therefore all.bash), as in CL https://go-review.googlesource.com/c/go/+/149967, it doesn't pass. Similar failures are seen when running race.bash on Linux/ARM64.
When using the race detector,
sync/atomic.StoreUint32and other sync/atomic functions are functions whose definitions and declarations are not in the same package, which therefore don't have implicit arg maps. It fails when those functions are called in defer statement.The text was updated successfully, but these errors were encountered: