Fix unwinding when throw is directly before catch #4191
Conversation
This file contains hidden or 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
…truction is directlly followed by catch. These can happen when LTO is enabled. Previously a finally block could have been not executed
…re uniqnes by unwinding point instead full identity
lolgab
reviewed
Jan 31, 2025
| @@ -42,6 +42,9 @@ private[monitor] class ObjectMonitor() { | |||
| */ | |||
| @volatile private var enterQueue: WaiterNode = _ | |||
|
|
|||
| override def toString(): String = | |||
| s"ObjectMonitor(owner=$ownerThread),waiting=$waiting,recursion=$recursion)" | |||
There was a problem hiding this comment.
Default toString don't return the parameter names but usually just ClassName(param1,param2,param3)
|
I see you changed the code reading LSDA to read some DWARF data. Is DWARF always available? How does it work? |
…ite loop in specific test cases
Not really, so far I have not observed them locally, but I've added the checks based on LLVM cxx_personality logic In theory at least lpBase can be used to have a correct landing pad but beside that I seems to not improve much |
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.
During LTO we were able to get into scenarios where we're throwing exception for which the catch handler is defined as a next instruction. Such cases were not handled before, but are handled by C++ exceptions handling.
The most impacting change include additional condition for
pcOffset == landingPadmeaning that if we're inside handler we should use it.This fixes problems where try-finally block executing
object.exitMonitorroutine was skipped leading to deadlocksInitially this PR was fixing fixing #4190 on my MacOS AArch64 machine, however it did not worked on Linux. After further inspection the change to check if we're at the start of next landing pad was leading in infinite loop in this test case #4190 (comment) becouse of that is should be right now treated as a refactor rather then a fix