I am getting a crash in DropShadower.
And as far as I can see, it’s because it has a bug. Or rather a shortcoming.
I am creating components dynamically and attach shadows to them. Those components are also deleted dynamically.
You cannot detach a component from a DropShadower. So even if my component is deleted, the DropShadower does not realise that.
My steps are the following:
- I create a component dynamically and attach a DropShadower to it. That sets the “owner” of the DropShadower to my newly created component. (“owner” is a member variable of DropShadower).
- I delete my component.
- I close the application. That triggers the destructor of the DropShadower. In the destructor of the DropShadower, it calls
But “owner” is no longer valid, because I already deleted the component in step 2. And therefore it crashes.
I think the solution would be, that DropShadower also overrides
Then it can detect, if its “owner” is being deleted. And in that case it can set the “owner” to nullptr.
NOTE: In this context “owner” is not the same as the parent! A DropShadower can (and should) have a different parent than its “owner”. The “owner” is the component, which the DropShadower follows around.
You can reproduce the problem with the attached JUCE project.
Run the project and press the four buttons in the order they are shown. I.e. first press “Create Component 1 With Shadows”. Then press “Delete Component 1”. Then press “Force Resized” and then press “Create Component 2”.
Once you did that, close the application. And then it should crash.
Note: It does not always crash. It depends on the memory layout. If you are “lucky” the deleted object is not yet fully overwritten and might still be partly executable (and then it would not crash).
I am running JUCE 6.0.7 on OSX Big Sur (Intel).
DrapShadowCrash.zip (5.3 KB)