Currently, access faults on memory mapped files on Windows (e.g.
from the drive the memory mapped file is on being ejected) cause
a runtime fault that can not be caught by debug.SetPanicOnFault.
On Unix systems, on the other hand, this causes a SIGBUS signal,
which can be caught by debug.SetPanicOnFault. Given that the
documentation of debug.SetPanicOnFault mentions handling memory
mapped files, this is arguably the correct behaviour.
Add handling, analogous to SIGBUS, to EXCEPTION_IN_PAGE_ERROR
on Windows, to allow for users to handle this error.
Fixes #58457
Change-Id: Ic7695fc01271f3552782089ac75c403d5279811f
Reviewed-on: https://go-review.googlesource.com/c/go/+/467195
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
_CTRL_SHUTDOWN_EVENT = 0x6
_EXCEPTION_ACCESS_VIOLATION = 0xc0000005
+ _EXCEPTION_IN_PAGE_ERROR = 0xc0000006
_EXCEPTION_BREAKPOINT = 0x80000003
_EXCEPTION_ILLEGAL_INSTRUCTION = 0xc000001d
_EXCEPTION_FLT_DENORMAL_OPERAND = 0xc000008d
default:
return false
case _EXCEPTION_ACCESS_VIOLATION:
+ case _EXCEPTION_IN_PAGE_ERROR:
case _EXCEPTION_INT_DIVIDE_BY_ZERO:
case _EXCEPTION_INT_OVERFLOW:
case _EXCEPTION_FLT_DENORMAL_OPERAND:
}
switch gp.sig {
- case _EXCEPTION_ACCESS_VIOLATION:
+ case _EXCEPTION_ACCESS_VIOLATION, _EXCEPTION_IN_PAGE_ERROR:
if gp.sigcode1 < 0x1000 {
panicmem()
}