runtime: don't crash on nil g in sigtramp on windows arm64 platform #50889
Conversation
|
This PR (HEAD: 824a4f4) has been imported to Gerrit for code review. Please visit https://go-review.googlesource.com/c/go/+/381775 to see it. Tip: You can toggle comments from me using the |
|
Message from Ian Lance Taylor: Patch Set 1: Run-TryBot+1 (4 comments) Please don’t reply on this GitHub thread. Visit golang.org/cl/381775. |
|
Message from Gopher Robot: Patch Set 1: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/381775. |
|
Message from Gopher Robot: Patch Set 1: TryBot-Result+1 (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/381775. |
This fixes the sigtramp handler on Windows. Note that unlike linuxy platforms, sigtramp is not actually a "trampoline" function. Instead, The code needed to handle interrupts in userspace is provided by Windows by some other means. On Windows the mechanism they provide is called "Vectored Exception Handling". Windows provides the AddVectoredExceptionHandler to register a callback function whenever an interrupt occurs which could be triggered by a signal/exception/etc. Windows supports multiple handlers and will call them one after the other stopping or continuing based on the return value as it goes along. In the case of go, it appears that sigtramp doesn't need to handle exceptions on threads that it hasn't initialized with the runtime. So in the case of windows, returning 0 from the exception handler will cause it to move on to the next exception handler. This is the change I've made here. This change has been built and verified to fix golang#43800 on a hololens arm64 windows device. Note that this also appears to be a problem for arm (sys_windows_arm.s). I'm currently not set up to test this on arm so maybe this could be fixed in a follow up change. Fixes golang#43800
marler8997
force-pushed
the
armSigtrampHandleGNil
branch
from
824a4f4 to
5602298
Compare
|
This PR (HEAD: 5602298) has been imported to Gerrit for code review. Please visit https://go-review.googlesource.com/c/go/+/381775 to see it. Tip: You can toggle comments from me using the |
marler8997
changed the title
|
Message from Jonathan Marler: Patch Set 4: (3 comments) Please don’t reply on this GitHub thread. Visit golang.org/cl/381775. |
|
Message from Cherry Mui: Patch Set 4: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/381775. |
|
Message from Jonathan Marler: Patch Set 4: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/381775. |
|
Message from Jonathan Marler: Patch Set 4: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/381775. |
|
Message from Cherry Mui: Patch Set 4: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/381775. |
|
Message from Jonathan Marler: Patch Set 4: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/381775. |
|
Message from Jonathan Marler: Patch Set 4: Code-Review-1 (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/381775. |
|
Message from Jonathan Marler: Patch Set 4: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/381775. |
This fixes the sigtramp handler on Windows. Note that unlike linuxy
platforms, sigtramp is not actually a "trampoline" function. Instead,
The code needed to handle interrupts in userspace is provided by
Windows by some other means. On Windows the mechanism they provide is
called "Vectored Exception Handling". Windows provides the
AddVectoredExceptionHandler to register a callback function whenever an
interrupt occurs which could be triggered by a signal/exception/etc.
Windows supports multiple handlers and will call them one after the other
stopping or continuing based on the return value as it goes along.
In the case of go, it appears that sigtramp doesn't need to handle
exceptions on threads that it hasn't initialized with the runtime. So
in the case of windows, returning 0 from the exception handler will
cause it to move on to the next exception handler. This is the change
I've made here.
This change has been built and verified to fix #43800 on a hololens
arm64 windows device.
Note that this also appears to be a problem for arm (sys_windows_arm.s).
I'm currently not set up to test this on arm so maybe this could be
fixed in a follow up change.
Fixes #43800