runtime: bad crash output for synchronous signal in the VDSO

[prattmic]

If a synchronous signal causes a crash in the VDSO, the output looks something like:

runtime: unexpected return pc for runtime.sigpanic called from 0x7ffd19ea9a4a
stack: frame={sp:0x7ffd19e600f8, fp:0x7ffd19e60148} stack=[0xc00004e000,0xc00004e800)

fatal error: unknown caller pc

runtime stack:
runtime.throw({0x4a1a18, 0x5197e0})
        /usr/local/google/home/mpratt/src/go/src/runtime/panic.go:965 +0x71
runtime.gentraceback(0x1000100000006, 0xc00004e800, 0x7ffd19e60160, 0x7ffd19ea9a4a, 0x0, 0x0, 0x7fffffff, 0x7ffd19e60170, 0x45ca0a, 0x0)
        /usr/local/google/home/mpratt/src/go/src/runtime/traceback.go:240 +0x1a36
runtime.addOneOpenDeferFrame.func1()
        /usr/local/google/home/mpratt/src/go/src/runtime/panic.go:585 +0x6b
runtime.systemstack()
        /usr/local/google/home/mpratt/src/go/src/runtime/asm_amd64.s:344 +0x49

goroutine 6 [running]:
runtime: unexpected return pc for runtime.systemstack_switch called from 0x0
stack: frame={sp:0x7ffd19e5fff0, fp:0x7ffd19e5fff8} stack=[0xc00004e000,0xc00004e800)

runtime.systemstack_switch()
        /usr/local/google/home/mpratt/src/go/src/runtime/asm_amd64.s:311 fp=0x7ffd19e5fff8 sp=0x7ffd19e5fff0 pc=0x458780
created by main.main
        /usr/local/google/home/mpratt/Downloads/hello.go:12 +0x76

goroutine 1 [semacquire]:
sync.runtime_Semacquire(0xc000010250)
        /usr/local/google/home/mpratt/src/go/src/runtime/sema.go:56 +0x25
sync.(*WaitGroup).Wait(0x0)
        /usr/local/google/home/mpratt/src/go/src/sync/waitgroup.go:136 +0x52
main.main()
        /usr/local/google/home/mpratt/Downloads/hello.go:16 +0x85

I manually triggered this crash by changing the runtime to pass a bad struct timespec * to clock_gettime in the VDSO.

Rather than the normal unexpected signal panic one would expect, gentraceback fails and throws. Luckily 0x7ffd19ea9a4a is the PC of the faulting instruction, which would help in an investigation, though it is not obvious from this output that that is the correct PC.

Synchronous signals panic by pushing sigpanic0 onto the stack and sigreturning to it. My quick investigation shows that gentraceback is computing the incorrect frame pointer, but I don't yet see why. I thought perhaps making preparePanic push vdsoSP instead of the actual SP might fix it, but it made no difference.

In practice, a synchronous signal in the VDSO would probably only occur due to a bug in the Go runtime, so this isn't high priority.

cc @cherrymui

[cherrymui]

My quick investigation shows that gentraceback is computing the incorrect frame pointer, but I don't yet see why.

The VDSO wrapper (e.g. runtime.nanotime1) switches to the g0 stack, align the SP (for C ABI), then calls the VDSO code. There may be C frames (from VDSO code) on that stack as well, that we simply don't know how to unwind.

I guess we just don't expecting synchronous signals in VDSO code. (We special-handled profiling signal. And we won't async preempt VDSO call.)

If we want, maybe we need some special handling for synchronous signals in VDSO code. Maybe if the faulting PC is from VDSO, we unwind the curg stack (instead of the g0 stack which is the running stack) from m.vdsoSP.

[prattmic]

I agree we don't expect synchronous signals in the VDSO. This only came up in my testing to investigate your question on http://golang.org/cl/339990.

I don't think we need to do anything now unless this comes up more.