[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: QDialog on stack+exec and dbus quit crash is no more
From:       Jan_Kundrát <jkt () flaska ! net>
Date:       2013-11-10 14:45:42
Message-ID: 7a51df16-0f53-40f6-bfb1-2d34f3342a4e () flaska ! net
[Download RAW message or body]

On Saturday, 9 November 2013 23:45:20 CEST, Albert Astals Cid wrote:
> But I don't think that's a problem anymore. I tried to crash it 
> by doing what 
> the blog says and it doesn't crash, and after having a look at the 
> KApplication::quit code that calls QCoreApplication::quit() 
> code I think that 
> this has been fixed in Qt since QCoreApplication::quit doesn't "destroy" 
> anything, just makes the event loops quit, so stuff is deleted properly.

It's still a problem because it starts a second event loop. The second 
event loop will process any events and there could easily be some 
application-level code which deletes some objects, perhaps the parent 
QWidget (of a parent of...) of the dialog.

I've wasted my fair share of time on this in Trojita where we disconnect 
from the IMAP server upon seeing a network error. This, naturally, leads to 
freeing memory of some auxiliary objects, and that was a problem when these 
objects were stuck in e.g. a GUI prompt for password.

The QPointer<QDialog> indeed looks like a kludge. The right way (tm) is, 
AFAIK, to use asynchronous state everywhere, i.e. have dialogs connected to 
slots of the object which triggered them. That's also the only way to do 
these prompts in QML, by the way. Yup, it's more code, but it's needed, 
IMHO.

Cheers,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
[prev in list] [next in list] [prev in thread] [next in thread]