NPAPI Plugin Issue: Refreshing causes null-pointer exception

I’m using the CallbackMessage::post() mechanism to trigger asynchronous events in JavaScript from another thread in my plugin and noticed a condition whereby the message is posted after npp has been freed:

[code] for (i = 0; i < numParameters; ++i)
browser.releasevariantvalue (&params[i]);

       if (browser.invoke (npp, source, getIdentifierFromString (methodName), 0, 0, &result))
            returnVal = createValueFromNPVariant (npp, result);
            browser.releasevariantvalue (&result);


I can fix this by tracking all allocated CallbackMessage instances in a list and flagging them as “invalid” from my BrowserPluginComponent destructor but just wondering first:

Is this a known problem?
Is there a built-in mechanism I should use do deal with this that I haven’t yet discovered?

Actually, after stepping back from this, why not just check npp == 0 and silently fail (inside Juce)? The only scenario this happens in is when a page is being unloaded.

What do you think Jules, Could you patch this in?

Sure, I can certainly add a check for a null pointer there - no problem. It’s a bit odd that it would call it though… If juce has shut down correctly, then any pending messages shouldn’t be delivered. Odd…

It’s kind of hard to debug it but the null pointer exception is 100% repeatable for me.

I’m using a very slow to initialise third-party library that is enumerating connected webcams in another thread. It posts a CallbackMessage to the message thread when its completed initialisation. The CallbackMessage triggers an asynchronous JavaScript callback function.

Sequence of events I presume are happening are:

  1. Juce thread for third-party library initialisation starts.
  2. Page unload requested. Juce starts shutting down.
  3. “Initialisation successful” CallbackMessage posted to the message thread. (Message thread is currently dealing with unloading the page.)
  4. Juce NPAPI cleanup tries to stop all Juce threads. My worker thread starts shutting down. (Shutdown is also very slow so it occasionally times out here, triggering a kill.)
  5. After Juce is done cleaning up, the next message is read off the Message queue and executed. This time we have no NPAPI handle though so we get a null pointer exception.