Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

runtime: bad crash output for synchronous signal in the VDSO #49156

Open
prattmic opened this issue Oct 25, 2021 · 2 comments
Open

runtime: bad crash output for synchronous signal in the VDSO #49156

prattmic opened this issue Oct 25, 2021 · 2 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Backlog

Comments

@prattmic
Copy link
Member

prattmic commented Oct 25, 2021 •
edited

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
@prattmic prattmic added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 25, 2021
@prattmic prattmic added this to the Backlog milestone Oct 25, 2021
@cherrymui
Copy link
Member

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
Copy link
Member Author

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.

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Projects
Go Compiler / Runtime
Status: Triage Backlog
Milestone
Backlog
Development

No branches or pull requests
3 participants
@prattmic @gopherbot @cherrymui