runtime/trace: frame pointer unwinding during C-to-Go calls can crash on amd64 #59830
Labels
compiler/runtime
Issues related to the Go compiler and/or runtime.
FrozenDueToAge
NeedsFix
The path to resolution is known, but the work has not been done.
Milestone
While attempting to enable frame pointer unwinding for execution tracing on arm64, I ran the
TestTraceUnwindCGO
test. This test crashes on arm64 during frame pointer unwinding. The test, unaltered, does not crash on amd64. However, I think amd64 is susceptible to the same issue, namely that there's a trace event during a C-to-Go call which currently gets a call stack via frame pointer unwinding when it probably shouldn't.We have the following logic in place to determine whether we're in a C-to-Go call:
go/src/runtime/proc.go
Lines 860 to 862 in 715d53c
If so, we fall back to regular unwinding, to avoid possibly following bad frame pointers coming from the C code. However, there is a point during the C-to-Go call where the "incgocallback" check is false, because
incgo == true
, yet we will still emit a trace event, duringreentersyscall
:go/src/runtime/cgocall.go
Lines 241 to 250 in 715d53c
I can make
TestTraceUnwindCGO
crash on amd64 by deliberately putting junk in RBP and confirming that the tracer attempts to unwind through the junk address:Then
go build ./testdata/testprogcgo
, thengdb ./testprogcgo
:I think we need something like an
incgocallback
boolean that's set to be true for the entirety ofcgocallbackg
, or at least something that covers thereentersyscall
call at the end ofcgocallbackg
.cc @felixge @mknyszek @prattmic
The text was updated successfully, but these errors were encountered: