runtime/pprof: failure in TestCPUProfile on windows/arm #42862
Comments
I started looking into this, but I must confess I don't know the pprof code very well. It looks like most stacktraces have an abundance of _System in them, which means that the tracing algorithm in runtime/proc.go's sigprof failed and resorted to _System as the final case for putting something down. It's not clear to me why the prior lookups are failing, though. I'm CCing @nodirt and @ianlancetaylor who seem to have written a lot of this code and might have better intuition than me on it. |
Change https://golang.org/cl/273826 mentions this issue: |
FYI, this is not a real fix. |
This is blocking forward progress of the de-bitrotting work, and I don't know off hand how to fix this. Seeing as its disabled on other platforms, I suspect pprof might not be a very reliable feature, so just allow for the tests to fail for now, until somebody more motivated comes along to fix it. Updates #42862. Change-Id: Ibc5cd1d82d97b9c2f887d7f3565f2fa70207c8b0 Reviewed-on: https://go-review.googlesource.com/c/go/+/273826 Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Trust: Jason A. Donenfeld <Jason@zx2c4.com>
I'm not familiar with the Windows profiling code. That said, I would start by looking at the values passed to |
I did notice at some point that enabling I don't have windows/arm to test with, but I'm wondering whether it would fail as well and point to the underlying issue? |
@zx2c4 you can try setting asyncpreemptoff, like in #42528 (comment) But I am grasping for straw. Long time ago I would debug these things just by adding println everywhere. You can do that. Make repro as small as you can, and see why it fails. Alex |
The text was updated successfully, but these errors were encountered: