DISTRHO / DPF

DISTRHO Plugin Framework
ISC License
671 stars 97 forks source link

Crash when deleting parent widget before the subwidget #346

Open jpcima opened 3 years ago

jpcima commented 3 years ago

Using DPF 1d756d6 from develop, in the case of a parent subwidget which has other subwidgets as children, deleting the parent leaves the children having a dangling parentWidget pointer.

The crash happens because of invalid access in SubWidget::PrivateData dtor. parentWidget->pData->subWidgets.remove(self);

falkTX commented 3 years ago

You have somewhere/something where this is happening right?

jpcima commented 3 years ago

spectacle-analyzer in with-new-dpf branch. The UI keeps a vector fSubWidgets which auto-deletes the elements. (note that deletion order of vector is undefined)

remark: this would never be a problem is dgl took care of widget ownerships by itself

falkTX commented 3 years ago

can you be more clear on your latest point? I thought this was already the case, when the subwidget is created and deleted it removes itself from the parent. doesnt a widget (top level or sub) delete its children on the destructor?

falkTX commented 3 years ago

wouldnt this be solved by a simple fSubWidgets.clear() on the (parent) widget destructor? so it deletes the children before itself.

jpcima commented 3 years ago

so it deletes the children before itself.

To elaborate, the problem is that it has 3 levels of widgets. example: UI →FloatingWindow → TextLabel. Delete FloatingWindow and then TextLabel, and it dies. This wouldn't happen in previous DPF.

doesnt a widget (top level or sub) delete its children on the destructor?

I'm pretty sure it doesn't, just clears the children array. (which are raw pointers)

falkTX commented 3 years ago

ok but then the owning part makes sense. it doesnt make sense to have to delete the child windows manually. The UI should destroy child windows, and all the way down as well.

btw, comparing to old DPF is not very helpful, old DPF didn't do a couple of things right.