runtime/race: race detector + pprof unstable since bb553699c7e6

[davecheney]

What steps will reproduce the problem?

The darwin/amd64-race and linux/amd64-race builders have been failing since 

https://code.google.com/p/go/source/detail?r=bb553699c7e6ee2764cd8ee812d30359d6131375

What is the expected output? What do you see instead?

ok      runtime/debug   1.082s
runtime: unknown argument frame size for runtime.asmcgocall
fatal error: invalid stack

goroutine 0 [idle]:
runtime: unknown argument frame size for runtime.sigtramp
panic during panic
FAIL    runtime/pprof   0.443s

Please use labels and text to provide additional information.

[dvyukov]

Comment 1:

Here are the functions that cause problems on race builders:
runtime: unknown argument frame size for runtime.asmcgocall
runtime: unknown argument frame size for runtime.sigreturn
runtime: unknown argument frame size for runtime.sigtramp
runtime: unknown argument frame size for runtime.raceread
I've also seen this one *without* -race when stackalloc crashed and wanted to unwind the
stack:
runtime: unknown argument frame size for runtime.morestack
Can preemptive scheduler make things even worse? C functions do have args info, right?
Part of the solution may be to not calculate args size when we are not doing GC, because
SIGPROF causes stack unwinding at unpredictable points.

[rsc]

Comment 2:

Can we just make pprof refuse to enable itself in race builds? Profiling won't give
useful data in that case anyway.

[dvyukov]

Comment 3:

I agree that profiling with -race is generally useless (it's useful for optimizing the
race detector itself, though).
But this is not race-specific bug. This is due to SIGPROF arriving before/after stack
frame allocation (SUB/ADD SP).

[rsc]

Comment 4:

Labels changed: added priority-later, removed priority-triage.

[davecheney]

Comment 6:

I am happy that the problems with the race builders around the time of this issue being
raised have been resolved and that this ticket should be closed.

Status changed to Fixed.