windows: SEH and VEH don't play well together

[zx2c4]

On Windows, there are two types of exception handling: structured exception handling (SEH) and vectored exception handling (VEH).

MSVC generates binaries with SEH, in which individual functions have exception handlers attached. On 64bit, these are stored in a table in the .pdata section of the PE. When a function throws an exception (say, due to an illegal instruction or a divide by zero), the SEH for it, if any, is called.

Go's runtime uses VEH, in which the entire runtime has a series of handlers that VEH jumps through until it reaches a termination point.

When an exception is thrown, ntdll executes VEH before SEH. This is reasonable behavior, but poses a problem for our use of VEH.

Recent MSVC toolchains generate arm64 DLLs that probe for ARMv8.1 atomics by testing some instructions, and using SEH to trap a potential illegal instruction exception indicating that those instructions aren't there. ARM64 DLLs generated by recent MSVC toolchains do this unconditionally during initialization.

When the Go runtime loads one of these recent DLLs (using LoadLibrary like normal), its VEH handler is called for the illegal instruction exception generated by the probing. The Go VEH handler then decides it's fatal, and quits. That's a big problem.

I see a few solutions to this:

1. We special case illegal instruction exceptions on arm64 that are thrown from outside Go's .text section, as I've done on https://go-review.googlesource.com/c/go/+/340070 . This works fine (and I'm shipping it now) and seems like the least invasive change. This could however, mask other illegal instruction exceptions that are thrown from outside Go's .text section that aren't subsequently caught and handled by SEH, in which case the binary will terminate without spitting out a stacktrace. That seems like an unlikely and insignificant edge case, however.

2. We always allow our VEH to fall through to SEH (or to nothing) if the exception comes from outside Go's .text section. This would work, but would also mean that legitimate crashes caused by library functions would not result in a Go stacktrace being printed. I sort of like this solution, but I can imagine why others might not. And those stacktraces are probably pretty useful. This would mean deleting the TestRaiseException unit test we have in runtime/.

3. We allow VEH to fall through to SEH if the exception comes from outside Go's .text section and there does exist an SEH for that function. This would be a more general case of (1), and perhaps a very good solution. I can probably do the reverse engineering necessary to implement this, though it's not easy. However, if an SEH then decided not to continue execution but to crash instead, we wouldn't print a stacktrace. It remains to be seen where that edge case would be hit.

4. We make our VEH call an SEH directly if it exists, and only crash with a stacktrace if the SEH called doesn't handle it. This is very tricky to do, but would probably give us the best of all worlds.

5. We do (2), but then install a SEH (using RtlAddFunctionTable) for the IP of syscall.Syscall that prints a stacktrace, so that we do ultimately get the unhandled exceptions that VEH passes on due to (2). This seems simple-ish, though I suspect we would miss stacktraces caused by threads created by non-Go code.

Before I go further in thinking about this, I thought we ought to discuss all this first. https://go-review.googlesource.com/c/go/+/340070 works as a stopgap solution for now, anyhow.

CC @rsc @ianlancetaylor @aclements @cherrymui @bradfitz @alexbrainman @jstarks

[gopherbot]

Change https://golang.org/cl/340070 mentions this issue: runtime: allow arm64 SEH to be called if illegal instruction

[zx2c4]

@jstarks If you've got opinions from a Windows perspective on what behavior seems most compliant, that'd carry a lot of weight. Our current maze of handlers is in https://github.com/golang/go/blob/master/src/runtime/signal_windows.go .

[jstarks]

I'm not sure yet. But one thing I want to point out is that Go's vectored exception handler (exceptionhandler) is already falling through to SEH. The vectored continue handlers are run unconditionally after VEH and SEH handling until one of them returns EXCEPTION_CONTINUE_EXECUTION.

I think ideally your VCH would only panic if none of the VEH or SEH handlers returned EXCEPTION_CONTINUE_EXECUTION. But I don't yet know if that information is available to you.

It seems like Go really just wants to be called for unhandled exceptions, but the unhandled exception filter isn't run for debugged processes, which is problematic. Is that right?

[zx2c4]

Oh, that's interesting. I didn't consider that the continued handlers were running after SEH. The reason is that that last continue handler appears to being called before the arm64 DLL's SEH, despite being "last". That's odd...

[jstarks]

Hmm. I don't immediately see how that's possible.

[zx2c4]

Bug? Try reverting 70546f6 and LoadLibrary'ing a DLL produced by the latest EWDK 22000 (here's one). You'll see that it dies when probing. Then add that commit back, and you'll see that it hits the interlocked probe exception handler. At least I think that's what's going on?

[jstarks]

I'll try to debug this in the next few days.

[gopherbot]

Change https://go.dev/cl/457875 mentions this issue: runtime,cmd/link: allow SEH tramps handle non-Go exception

[qmuntal]

I've implemented option 5 in CL 457875. Still WIP but looks promising. Edit: missed exception on non-go threads might render this option unusable.