runtime/race: use runtime.CallersFrames

[josharian]

The backtraces from the race detector don't include inlined frames. But we now have that information available, via runtime.CallersFrames. It'd be nice to use it.

I went to look at adding this myself, but I'd need a few pointers--the race detector code is out of tree, and I can't find the place where the race detector traceback interacts with the Go runtime.

cc @dvyukov

[ianlancetaylor]

The race detector run time support calls back into Go to print a stack trace. The callback function is passed to the race detector in the call to __tsan_init from raceinit in runtime/race.go. The callback function is racecallbackthunk, defined in runtime/race_amd64.s. It calls racecallback in runtime/race.go, which calls FuncForPC to get the Go function name.

The PC values passed to FuncForPC are collected by calls to racefuncenter and racefuncexit inserted by the compiler (cmd/compile/internal/gc/racewalk.go).

So, yes, it would be nice to use CallersFrames, but it's not clear that we have the right data or API.

[dvyukov]

Re API: yes, need to extend it to make it possible to return several frames. Tsan runtime itself was always able to deal with inlined frames, so it's only tsan<->Go interface that needs to be changed.

Re right data: @ianlancetaylor why do you suspect that the data may not be right? Why calling CallersFrames with a single PC may not work?

[ianlancetaylor]

Calling CallersFrames with a single PC will work, but I think that only collecting PCs at function entry points won't produce sufficient info when using mid-stack inlining. If F calls G calls H calls I, and the middle is inlined, the race detector may report a stack trace showing F calling I. To get the correct stack trace it needs to have not just the PC when it enters I, but the PC within F that calls I.

Perhaps the race detector does collect that, and I just understand how it works.

[dvyukov]

@ianlancetaylor on function entry it obtains caller pc, so it's actually call site. So everything should work.

[bcmills]

Just ran into this again while investigating #36431.

[randall77]

Hmmm, I thought I fixed this in the fix for #33309.

[randall77]

Are you sure you saw a missing frame using 1.14? I don't see any missing frames. I get the same trace you did in #36431 where you said you turned inlining off. I didn't turn inlining off.

[bcmills]

Hmm, must've been with go1.13.5 instead. I just tried go1.14beta1 and gotip again and I seem to be getting complete stack traces with those.

[randall77]

Phew, thanks. I'm going to close this issue then.