Disable Mach exception handlers when read barriers in place #5991
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
KJTsanaktsidis
force-pushed
the
ktsanaktsidis/skip_debugger_in_compaction
branch
from
8aaa364
to
3f0d2ca
Compare
nobu
reviewed
Jun 8, 2022
gc.c
Outdated
| static mach_msg_type_number_t old_exception_count; | ||
|
|
||
| static void | ||
| disable_mach_bad_access_exc() |
There was a problem hiding this comment.
Suggested change
| disable_mach_bad_access_exc() | |
| disable_mach_bad_access_exc(void) |
nobu
reviewed
Jun 8, 2022
gc.c
Outdated
| } | ||
|
|
||
| static void | ||
| restore_mach_bad_access_exc() |
There was a problem hiding this comment.
Suggested change
| restore_mach_bad_access_exc() | |
| restore_mach_bad_access_exc(void) |
The GC compaction mechanism implements a kind of read barrier by marking some (OS) pages as unreadable, and installing a SIGBUS/SIGSEGV handler to detect when they're accessed and invalidate an attempt to move the object. Unfortunately, when a debugger is attached to the Ruby interpreter on Mac OS, the debugger will trap the EXC_BAD_ACCES mach exception before the runtime can transform that into a SIGBUS signal and dispatch it. Thus, execution gets stuck; any attempt to continue from the debugger re-executes the line that caused the exception and no forward progress can be made. This makes it impossible to debug either the Ruby interpreter or a C extension whilst compaction is in use. To fix this, we disable the EXC_BAD_ACCESS handler when installing the SIGBUS/SIGSEGV handlers, and re-enable them once the compaction is done. The debugger will still trap on the attempt to read the bad page, but it will be trapping the SIGBUS signal, rather than the EXC_BAD_ACCESS mach exception. It's possible to continue from this in the debugger, which invokes the signal handler and allows forward progress to be made.
KJTsanaktsidis
force-pushed
the
ktsanaktsidis/skip_debugger_in_compaction
branch
from
3f0d2ca
to
6276a29
Compare
|
Thanks for the feedback @nobu, I updated the function prototypes to be properly empty. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The GC compaction mechanism implements a kind of read barrier by marking
some (OS) pages as unreadable, and installing a SIGBUS/SIGSEGV handler
to detect when they're accessed and invalidate an attempt to move the
object.
Unfortunately, when a debugger is attached to the Ruby interpreter on
Mac OS, the debugger will trap the EXC_BAD_ACCES mach exception before
the runtime can transform that into a SIGBUS signal and dispatch it.
Thus, execution gets stuck; any attempt to continue from the debugger
re-executes the line that caused the exception and no forward progress
can be made.
This makes it impossible to debug either the Ruby interpreter or a C
extension whilst compaction is in use.
To fix this, we disable the EXC_BAD_ACCESS handler when installing the
SIGBUS/SIGSEGV handlers, and re-enable them once the compaction is done.
The debugger will still trap on the attempt to read the bad page, but it
will be trapping the SIGBUS signal, rather than the EXC_BAD_ACCESS mach
exception. It's possible to continue from this in the debugger, which
invokes the signal handler and allows forward progress to be made.
More info in the bug: https://bugs.ruby-lang.org/issues/18796