-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Graphics.close_graph crashes 64-bit Windows ports #678
Conversation
At the moment, this implementation won't release two separate threads both blocking on |
MPR3963 incorrectly fixed in 4.01.0. Closing the graphics window will now cause calls to Graphics.wait_next_event to terminate (which was the original MPR) and calling Graphics.close_graph no longer crashes the 64-bit runtime.
(updated Changes file) |
Thanks for finding and fixing this bug! |
Graphics.close_graph crashes 64-bit Windows ports
Rebased and merged into trunk. |
No worries - could the fix go in 4.03 too? |
I don't think any bugfix release in planned on 4.03. |
Ah, fair enough! |
Graphics.close_graph crashes 64-bit Windows ports
* Rebase * ocamlformat * Disable CFG tests. * Restore ocamlcfg tests. * Prologue * Revert dataflow changes. * Revert dataflow changes. * Format * Use the dedicated flag. * Review * Review * CRs * Review * ocamlformat * Arm64 * Review * Review * Review * Review * ocamlformat * Fix review change * Debugging tweaks. * ocamlformat * Review. * ocamlformat Co-authored-by: Greta Yorsh <gyorsh@janestreet.com>
A fix for MPR3963 was added in b147d07 (released in 4.01.0) by @damiendoligez. As far as I can see, this fix never worked: I think it's fundamentally broken and on the 32-bit Windows ports it doesn't work and on the 64-bit Windows ports, it causes
Graphics.close_graph
to bring down the runtime.I believe the original intention was that closing the graphics window (via the X button) should result in any calls to
Graphics.wait_next_event
terminating with:but this is done by causing WM_DESTROY to raise an OCaml exception - but the window handler is in a non-OCaml thread, so it cannot possibly raise OCaml exceptions?