Deletion checker needed in Component::internalMouseEnter?

1

Doing some testing with ASAN revealed a heap-use-after-free here:

void Component::internalMouseEnter (MouseInputSource source, Point<float> relativePos, Time time)
...
    HierarchyChecker checker (this, me);    
    mouseEnter (me);
    // ASAN reports violation on the next line:
    flags.cachedMouseInsideComponent = true;

One potential fix, which fixes things for me:

+   WeakReference<Component> deletionChecker (this);
    mouseEnter (me);
+   if (!deletionChecker)
+       return;
    flags.cachedMouseInsideComponent = true;

I see that there is already a HierarchyChecker being used here. My read of the code is that that only checks if parent Component instances have been deleted, not the component itself.

Should JUCE add checks to protect against this sort of thing (here and likely other similar mouse methods)?

Thanks,
Rob

2

Can you provide a bit more context on how this happened?

Why was the component deleted, etc?

3

Hi Oli, good question. I’m happy to give a little more context, but I’m not sure how useful that context is.

First, let’s just assume there is no good reason for a component to delete itself from inside mouseMove. Given that, is it still a reasonable thing for JUCE to protect against it? I’d totally understand if JUCE defines it to be undefined behavior for a component to delete itself in any of the mouse method callbacks, but it is not difficult to protect against it, so maybe it should considering the general audience that JUCE serves?

Now just because you asked, in my particular case it goes something like this. A TreeView-derived control has custom components inside, one of which upon mouse enter makes a call that ends up refreshing the tree which causes the whole thing to be torn down and rebuilt in certain situations. Not ideal of course, and can certainly be improved, but that’s the general situation.