[Development] Clarification needed on a crash caused by ignoring ownership of an object

Marc Mutz marc.mutz at kdab.com
Thu May 4 10:08:13 CEST 2017


On Thursday 04 May 2017 09:58:45 Andy Shaw wrote:
> Hi,
> 
> I am trying to determine what we should be doing inside Qt in a certain
> case. When a QUndoCommand is deleted after it has been given another
> QUndoCommand as a parent it will cause a crash since the parent has not
> been informed that the child was deleted. The documentation for
> QUndoCommand is explicit on the fact that when it has a parent the
> ownership of the QUndoCommand is transferred to its parent. As such I
> would not expect it to be possible to delete the child directly anymore as
> a result as we no longer own it.
> 
> So the question is, since it is still a crash, should we still be
> accounting for this in the Qt code so as to prevent the crash or is it a
> case of it is documented to transfer ownership and as such we don’t want
> to protect against it being deleted out of Qt’s hands?

Seeing as about half of the ubsan reports are about shutdown sequences of 
object hierarchies which allow parent-owned children to be deleted by the 
user, I'm tempted to say: add an assert (set a flag when the parent deletes a 
child, check that the flag is set in the child's dtor).

OTOH, QObject parent-child relationships, and QTreeWidgetItems set a strong 
precedent.

I'd decide based on how much complexity this adds to the implementation, but 
if you prepare a patch, the pressure to merge it is going to be a great one. 
The work is already done, after all. So, please decide yourself. You have my 
blessing to close as WONTFIX, or else enable the new use-case if it's not too 
complex (a very subjective criterion, I agree).

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts



More information about the Development mailing list