Open ollie-dawes opened 1 year ago
Really thanks for your excellent solution! Using QPointer is really a good idea. But can you make a PR for it?
But this issue also makes me worried. Currently FramelessHelper is using QWindow pointer to identify different instances, I didn't account for the case that the QWindow itself is destroyed (because currently I don't have a good way to get notified before a QWindow is about to be destroyed, the QObject::destroyed signal is too late), it may be a potential bug source.
Really thanks for your excellent solution! Using QPointer is really a good idea. But can you make a PR for it?
Sure, here's a pr with the fix: https://github.com/wangwenx190/framelesshelper/pull/305
I would not be surprised if there are other lifetime issues as well with some of these other lambda callbacks but so far I have not seen any other issues.
Sure, here's a pr with the fix: https://github.com/wangwenx190/framelesshelper/pull/305
Thanks! It has been merged just now.
I would not be surprised if there are other lifetime issues as well with some of these other lambda callbacks but so far I have not seen any other issues.
It seems this lambda dispatching mechanism is a little more fragile than I would expect, but this is the first crash report so far, so maybe it's not that fragile 😂
As of commit: c4a7bc80d0ca0b1b87418515ab4836f3d4944ae0
Application can crash on Windows (Qt 6.6) in the
FramelessHelperHookWindowProc
callback if the underlyingQWindow
has already been deleted.Ran into this issue when testing out the latest https://github.com/KDAB/KDDockWidgets, the below crash happens after the window is "docked".
The above crash is due to the following capture of the FramelessQuickHelper* in a lambda here:
Which is invoked by the
FramelessHelperHookWindowProc
callback here (line 912):uMsg
in this case isWM_SHOWWINDOW
for what it is worth.The following patch fixes the issue on my end by capturing a
QPointer
to theQWindow
instead of the rawFramelessQuickHelper*
:fix.patch