-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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: crash in race detector when execution tracer reads from CPU profile buffer #65607
Comments
Oops, I suspect this is a consequence of https://go-review.googlesource.com/c/go/+/555495. The race annotation in profBuf.read is manual, perhaps we could borrow a racectx, or maybe even safely skip it altogether (not sure that is a great idea)? cc @mknyszek |
@gopherbot Please backport to 1.22. This causes random crashes when using race+trace+cpu profiling. |
Backport issue(s) opened: #65644 (for 1.22). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
Change https://go.dev/cl/562998 mentions this issue: |
Change https://go.dev/cl/562996 mentions this issue: |
This would have caught #65607. On my machine: internal/trace/v2: ~13s internal/trace/v2: -short: ~4s internal/trace/v2: -race -short: ~20s internal/trace/v2: -race: ~46s For #65607. Change-Id: I03a555ebaf8c761c98a82b6d35fa16d7a99aa9e3 Reviewed-on: https://go-review.googlesource.com/c/go/+/562998 Auto-Submit: Michael Pratt <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Michael Knyszek <[email protected]>
Change https://go.dev/cl/562559 mentions this issue: |
…m stack traceReadCPU calls profBuf.read, which does a raceacquire. g0 does not have a race context, so this crashes when running on the system stack. We could borrow a race context, but it is simpler to just move traceReadCPU off of the system stack. For #65607. Fixes #65644. Change-Id: I335155b96d683aebb92b2f4e1eea063dd139f2d5 Reviewed-on: https://go-review.googlesource.com/c/go/+/562996 Auto-Submit: Michael Pratt <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Michael Knyszek <[email protected]> (cherry picked from commit 9fa153b) Reviewed-on: https://go-review.googlesource.com/c/go/+/562559
traceReadCPU calls profBuf.read, which does a raceacquire. g0 does not have a race context, so this crashes when running on the system stack. We could borrow a race context, but it is simpler to just move traceReadCPU off of the system stack. Fixes golang#65607. Change-Id: I335155b96d683aebb92b2f4e1eea063dd139f2d5 Reviewed-on: https://go-review.googlesource.com/c/go/+/562996 Auto-Submit: Michael Pratt <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Michael Knyszek <[email protected]>
This would have caught golang#65607. On my machine: internal/trace/v2: ~13s internal/trace/v2: -short: ~4s internal/trace/v2: -race -short: ~20s internal/trace/v2: -race: ~46s For golang#65607. Change-Id: I03a555ebaf8c761c98a82b6d35fa16d7a99aa9e3 Reviewed-on: https://go-review.googlesource.com/c/go/+/562998 Auto-Submit: Michael Pratt <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Michael Knyszek <[email protected]>
…m stack traceReadCPU calls profBuf.read, which does a raceacquire. g0 does not have a race context, so this crashes when running on the system stack. We could borrow a race context, but it is simpler to just move traceReadCPU off of the system stack. For golang#65607. Fixes golang#65644. Change-Id: I335155b96d683aebb92b2f4e1eea063dd139f2d5 Reviewed-on: https://go-review.googlesource.com/c/go/+/562996 Auto-Submit: Michael Pratt <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Michael Knyszek <[email protected]> (cherry picked from commit 9fa153b) Reviewed-on: https://go-review.googlesource.com/c/go/+/562559
…m stack traceReadCPU calls profBuf.read, which does a raceacquire. g0 does not have a race context, so this crashes when running on the system stack. We could borrow a race context, but it is simpler to just move traceReadCPU off of the system stack. For golang#65607. Fixes golang#65644. Change-Id: I335155b96d683aebb92b2f4e1eea063dd139f2d5 Reviewed-on: https://go-review.googlesource.com/c/go/+/562996 Auto-Submit: Michael Pratt <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Michael Knyszek <[email protected]> (cherry picked from commit 9fa153b) Reviewed-on: https://go-review.googlesource.com/c/go/+/562559
Go version
go version go1.22.0 linux/amd64
Output of
go env
in your module/workspace:What did you do?
Ran this program, compiled with the race detector enabled:
What did you see happen?
The program crashes with a segfault during a race detector call:
crash output
Here's the traceback from a debugger:
It's faulting on the first instruction in
__tsan::Acquire
, looks like the first argument is 0:What did you expect to see?
No crash.
FWIW, it seems like the combination of race detector + execution tracer + CPU profiler, on Go 1.22, is not working. If I just run the CPU profiler, without the tracer, I don't see the crash. I also tried with Go 1.21.7 and didn't see a crash.
The text was updated successfully, but these errors were encountered: