On Wednesday 22 May 2024 06:38:28 GMT-3 Volker Hilsheimer via Development wrote: > As long as Qt is built with exception support
We don't support toggling that on and off any more and haven't for a while. QtCore and QtGui are compiled with exceptions enabled; all the other modules are not. In paticular, QtWidgets is not and that therefore applies to QApplication::notify(). That means you MUST NOT let exceptions run through the event loop of a Widgets application. You shouldn't let it happen for any application because Bad Things Will Happen™ because we don't test what happens if you do. Your very best bet is that you end up back in main() where you can do an emergency save using non-Qt code and terminate the application. But since we don't test, we can't guarantee that even the exceptions-enabled code in QtCore and QtGui won't just crash because of some unsuspected condition being violated. > There might be code paths (esp on macOS) that go into the native functions > and back into Qt, and perhaps some of those native stack frames eat the > exception or don’t pass it on otherwise. As far as I understand, the problem is that on ARM, there *is* no native stack frame, unlike on x86. Stack unwinding on x86 is very frequently possible because the architecture saves the return address on the stack and most code is compiled with frame pointers, even when exceptions are disabled. On ARM and other RISC architectures, the return address is saved in a register and it's the responsibility of the prologue of the called function to save it somewhere in the stack if it is not a leaf function. The problem is answering: where? This requires reading the unwind information. Which isn't present in QtWidgets. That explains why Dennis reports being able to throw through QApplication::notify() on Intel Macs but not on ARM Macs. Plus, yes, we often have frames from third party libraries in our stack that aren't capable of unwinding the stack either. Therefore, the Qt recommendation is that you treat all event handlers and all slot invocations as noexcept and catch your own exceptions before they go back to Qt code. This is the reason why we decided it was ok to disable exceptions in QtWidgets itself, because we didn't think we could guarantee survivability in the first place. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
