QDialog on stack+exec and dbus quit crash is no more

[Albert Astals Cid]

El Diumenge, 10 de novembre de 2013, a les 15:45:42, Jan Kundrát va escriure:
> 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.

Which events will it process when you do dbus quit that are not processed in 
general?

> 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.

Not sure you're understanding what i say, we have an explicit check about 
QDialog on stack+exec that says "it will crash if you dbus quit".

What I'm saying is that this doesn't happen anymore and we should remove that 
check. You're saying that nested event loops are bad, and that's totally 
right, but can't see how it's related to what i said.

Cheers,
  Albert

> 
> Cheers,
> Jan