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

runtime: access faults to memory mapped files on windows can't be caught by using SetPanicOnFault #58457

Closed
secDre4mer opened this issue Feb 10, 2023 · 3 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. OS-Windows
Milestone

Comments

@secDre4mer
Copy link
Contributor

What version of Go are you using (go version)?

$ go version
go 1.19

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

windows/amd64

What did you do?

Memory map a file on an external disk (using CreateFileMapping / MapViewOfFile)
Call debug.SetPanicOnFault(true)
Eject the external disk
Try to read from the memory map

What did you expect to see?

The read should cause a panic since the access fails.

What did you see instead?

The runtime faults (Exception 0xc0000006 0x0 ...) instead of panicing, thus preventing the user from recovering from this error.

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Feb 10, 2023
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/467195 mentions this issue: runtime: Allow handling of EXCEPTION_IN_PAGE_ERROR

@qmuntal
Copy link
Contributor

qmuntal commented Feb 10, 2023

@golang/windows

@qmuntal
Copy link
Contributor

qmuntal commented Feb 10, 2023

Windows docs seems to back @secDre4mer proposed solution (implemented in CL 467195): https://learn.microsoft.com/en-us/windows/win32/memory/reading-and-writing-from-a-file-view

Reading from or writing to a file view of a file other than the page file can cause an EXCEPTION_IN_PAGE_ERROR exception. For example, accessing a mapped file that resides on a remote server can generate an exception if the connection to the server is lost. Exceptions can also occur because of a full disk, an underlying device failure, or a memory allocation failure.

@bcmills bcmills added this to the Backlog milestone Feb 10, 2023
@dr2chase dr2chase added the NeedsFix The path to resolution is known, but the work has not been done. label Feb 10, 2023
johanbrandhorst pushed a commit to Pryz/go that referenced this issue Feb 12, 2023
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 golang#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>
@golang golang locked and limited conversation to collaborators Feb 11, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. OS-Windows
Projects
None yet
Development

No branches or pull requests

5 participants