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

List:       kde-devel
Subject:    Re: Not used QPointers showing modal dialogs via exec() - No crash
From:       Harsh Kumar <harsh1kumar () gmail ! com>
Date:       2013-11-12 7:36:30
Message-ID: CAFfwLZg2hQ_DE8uCP0VEAug9ZsfWTyPv1TVLjYS5ucJ0_6c6Ag () mail ! gmail ! com
[Download RAW message or body]

On 11/12/13, Thomas L=FCbking <thomas.luebking@gmail.com> wrote:
> On Montag, 11. November 2013 19:42:13 CEST, Kevin Krammer wrote:
>
>> If anything, D-Bus, timer, whatever, causes deletion of the
>> dialog's parent,
>> in this case KMinesMainWindow, then it will delete its child QObject.
>
> If a QObject with children on the stack gets deleted, you're in trouble
> anyway, see the big fat warning in the QObject API about this.
>
>> When the C++ code of the functions cleans up the stack, it will
>> at least also
>> invoke the dialog's destructor.
>
> This however would bite you if the deconstructor attempts to operate on t=
he
> deleted parent()
>
>
> Long story short:
> -----------------
> if you cannot ressonably assume -or even better: guarantee- that the
> environment is gonna survive the nested eventloop:
>
> a) create the object with nested loop on the heap and assign it a qpointer
> b) check whether the nested pointer is NULL after the nested loop has quit
> c) if you need to perform more stuff on "this" after the nested loop has
> exited, assign a qpointer to "this" before entering the loop and check it
> afterwards as well (for odds are good that "this" has gone as well)
> d) actually better guard any ("toplevel") pointers that you intend to acc=
ess
> after a nested event loop.
>
> Alternatively under this (unsafe state) condition, just don't use a nested
> eventloop.
>
> Cheers,
> Thomas
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscri=
be
>>> <<
>

So, this is what I gather from the discussion.

1. If there is some code after exec() then code will crash as the
QObject has been deleted.
In this particular case, there is no code after exec().

2. Even if there is no code after exec(), there can be a crash when
stack is cleared while returning from the function.
However, the problem is that here we are not seeing a crash. It seems
the code can be potentially dangerous, but is not crashing in this
case.

3. In any case, such nested eventloops should be avoided. But if used,
then object must be created on heap & there should be appropriate
checks before using the object to check if it is still valid.

I hope I have made the correct observations, right?

-- =

Harsh Kumar

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=
e <<
[prev in list] [next in list] [prev in thread] [next in thread]