Fix exception handling on Windows

GO uses AddVectoredExceptionHandler/AddVectoredContinueHandler on
Windows to setup its handling of exceptions on Windows (for recovering
from some kind of exceptions like divide by zero and various overflows
situations that can be handled nicely in Go). In the context of CGO, the
registered exception/continue handlers use isgoexception() to determine
if they should handle the exception, or let whatever other handler has
been registered do its work (typical exemple, is when calling C/C++ code
with CGO, and having a C debugger introducing a breakpoint in non-go
code).

The last handler in the chain misses this check. This is usually ok, but
in some cases, when a user attaches a non-go debugger to a CGO enabled
process, non-go breakpoints can actually be catched by this handler which
panics and stop the execution.

The problem was discovered by building a go package in c-shared mode,
and using it from a C# application. Whenever a go routine callbacks a
a function defined in C#, it panics if the .Net debugger is attached
(and runs fine otherwise).

This commit fixes this behavior by ignoring exceptions originating from
non-go code in the last continue handler.

Signed-off-by: Simon Ferquel <[email protected]>

Author: simonferquel

src/runtime/signal_windows.go

@@ -171,6 +171,9 @@ var testingWER bool
 //
 //go:nosplit
 func lastcontinuehandler(info *exceptionrecord, r *context, gp *g) int32 {
+	if !isgoexception(info, r) {
+		return _EXCEPTION_CONTINUE_SEARCH
+	}
 	if testingWER {
 		return _EXCEPTION_CONTINUE_SEARCH
 	}