- Notifications
You must be signed in to change notification settings - Fork380
Fix unwinding when throw is directly before catch#4191
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
…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
| @volatileprivatevarenterQueue:WaiterNode= _ | ||
| overridedeftoString():String= | ||
| s"ObjectMonitor(owner=$ownerThread),waiting=$waiting,recursion=$recursion)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Default toString don't return the parameter names but usually justClassName(param1,param2,param3)
I see you changed the code reading LSDA to read some DWARF data. Is DWARF always available? How does it work? |
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 |
Uh oh!
There was an error while loading.Please reload this page.
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