[Interest] [Qt bugreports] (QTBUG-54098) crash in QCoreApplication::postEvent() after a QScopedPointer<QActionGroup, QScopedPointerDeleteLater> goes out of scope

[René J.V. Bertin]

On Tuesday June 14 2016 14:59:47 Thiago Macieira wrote:

Continuing this on the ML:

> 	Thiago Macieira commented on  QTBUG-54098
>  
> Re: crash in QCoreApplication::postEvent() after a QScopedPointer<QActionGroup,QScopedPointerDeleteLater> goes out of scope
> Shouldn't the test on "posting during destruction" include a check if pdata!=NULL, possibly even if receiver->d_func() doesn't return NULL?
> No, it doesn't need to. The code is:
>     QThreadData * volatile * pdata = &receiver->d_func()->threadData;
> receiver can't be null (it was checked a few lines above). For a valid QObject, the d pointer can't be null. It just can't.
> Since it can't be null, pdata is not null.

A valid QObject always has a non-null threadData member? 
But how do you test if a QObject* is valid, and not stale? 

> Conclusion: you passed a dangling pointer to postEvent(). The bug is in your code.

Erm, no, it's not me who passed a stale pointer to postEvent(). My code doesn't even call that function; I'm pretty sure that the crash wouldn't occur if I managed to activate the remove menu action without using the mouse. I know that it was most likely my fault that the object in question was deleted while events could still be delivered to it, but IMHO the real bug here is that it's so easy to find yourself in that situation.
If QObjects are preferably to be destroyed via deleteLater (when they correspond to a UI element), shouldn't their automatic deletion when the parent object is deleted be handled through deleteLater() or something similar, instead of delete?

R.