TBC - All hell breaks loose - finally is also broken and more...
Thanks to Alexander Benikowski and Stefan Glienke for bringing this fact to my attention. And this part is NOT DOCUMENTED, though it is logical - if you cannot find your way back to the except block, you cannot find your way back to the finally either.
Dalija Prasnikar that's what i was afraid of when Stefan Glienke and i talked about this weird behavior earlier today after i read your blog. But it seems the implicit finally works when no explicit finally exists. So there is even an extra condition on top of this mess. It sounds really dangerous to work with raw stuff on mobile...
Dalija Prasnikar now imagine the Linux-Compiler wasn't ARC-Based and therefore required manual try/finally guards everywhere. That whould be even more dangerous!
For context - and not saying this bug is not bad - it is a LLVM issue. It's also surprisingly difficult to fix. Google tried back in about 2015 or so, hoisting the call into a fake method. I do not know the details but it was not successful.
I cannot get division by zero by default, and if I clear FPU exception mask, the whole application gets killed on Android after it raises one. Even on Windows FMX app goes nuts when I do that.
Dalija Prasnikar No, I don’t know how to enable them, or if it is possible or supported.
I just thought of FPU exceptions as a hardware exception that is more logical and “expected” than Access Violations, Segment faults etc. Often used to protect against illegal inputs without too many manual checks.
Hallvard Vassbotn making virtual call on nil reference creates AV that breaks exception handling.
While you can check for nil before you do that, I have seen a lot of code that just allows tripping on nil if this represents an error and has exception handling in place to take care of such exceptional situations.
I cannot say which ones are more logical and expected :)
One more thing to keep in our heads....
ReplyDeleteWait what? They just use the Landingpad approach? :(
ReplyDeletehttps://bugs.llvm.org/show_bug.cgi?id=1269
ReplyDeleteTBC - All hell breaks loose - finally is also broken and more...
ReplyDeleteThanks to Alexander Benikowski and Stefan Glienke for bringing this fact to my attention. And this part is NOT DOCUMENTED, though it is logical - if you cannot find your way back to the except block, you cannot find your way back to the finally either.
Dalija Prasnikar that's what i was afraid of when Stefan Glienke and i talked about this weird behavior earlier today after i read your blog. But it seems the implicit finally works when no explicit finally exists. So there is even an extra condition on top of this mess. It sounds really dangerous to work with raw stuff on mobile...
ReplyDeleteAlexander Benikowski and Linux
ReplyDeleteThings are getting worse with every comment...
ReplyDeleteChristen Blom-Dahl Current OSX compiler is not LLVM based, does that make you feel better?
ReplyDeleteOf course, Windows compilers are not affected.
Thank you Dalija Prasnikar, now I feel much better. But I keep asking me what to do with my NEXTGEN stuff.
ReplyDeleteDalija Prasnikar now imagine the Linux-Compiler wasn't ARC-Based and therefore required manual try/finally guards everywhere. That whould be even more dangerous!
ReplyDeleteAlexander Benikowski I imagine that most of the code running on all platforms originated from Windows code - with try...finally all over the place.
ReplyDeleteFor context - and not saying this bug is not bad - it is a LLVM issue. It's also surprisingly difficult to fix. Google tried back in about 2015 or so, hoisting the call into a fake method. I do not know the details but it was not successful.
ReplyDeleteDavid Millington I am not saying it is easy to fix. I assume if it was easy, exception handling would not be broken in the first place.
ReplyDeleteBut this completely destructs code fabric, so to speak. Everything is broken...
Also, if constructor throws hardware exception, regular cleanup is completely broken - destructor chain is not called, FreeInstance is not called...
On the bright side, constructor itself contains the exception, and exception handling around it functions properly.
Another problem is finding which exceptions really are "hardware" exceptions that break things, besides obvious AV exceptions.
How about FPU exceptions?
ReplyDeleteHallvard Vassbotn do you know how to raise one?
ReplyDeleteI cannot get division by zero by default, and if I clear FPU exception mask, the whole application gets killed on Android after it raises one. Even on Windows FMX app goes nuts when I do that.
Dalija Prasnikar No, I don’t know how to enable them, or if it is possible or supported.
ReplyDeleteI just thought of FPU exceptions as a hardware exception that is more logical and “expected” than Access Violations, Segment faults etc. Often used to protect against illegal inputs without too many manual checks.
Hallvard Vassbotn making virtual call on nil reference creates AV that breaks exception handling.
ReplyDeleteWhile you can check for nil before you do that, I have seen a lot of code that just allows tripping on nil if this represents an error and has exception handling in place to take care of such exceptional situations.
I cannot say which ones are more logical and expected :)