Closed Bug 517923 Opened 13 years ago Closed 13 years ago

Electrolysis: PluginModuleChild::_geturl crashes on NULL char*, needs to serialize them


(Core :: Plug-ins, defect, P1)

Windows NT





(Reporter: benjamin, Assigned: cjones)



I was trying to run the plugin unit tests on Electrolysis. If the plugin is unloaded and then reloaded, the plugin process is defunct: we try to send a message to it which hangs forever.

Related to bug 516509 but it should be possible to deal with these lifetime issues while keeping the magic/awful singleton.
Steps to reproduce:

* un-do so that mochitests turn on plugin-IPC (rebuild testing/mochitest)
* cd objdir/_tests/testing/mochitest
* python --test-path=modules/plugin/test/test_pluginstream.html

This test instantiates the plugin multiple times (in order to do variations on the test). At the second instantiation the first mozilla-runtime process is defunct but we're trying to send it a message.
Assignee: nobody → jones.chris.g
Priority: -- → P1
This particular crash points at a bug in the XPCOM string code, bug 518001.

But the underlying problem is more general, which is that NULL is sometimes meaningful for NPAPI interfaces (NPN_GetURL(), e.g.) and we need to serialize NULL.  The tentative plan is to use "void" ns*String*s to represent NULL.
Summary: Electrolysis: if the plugin is unloaded and re-instantiated the browser hangs → Electrolysis: PluginModuleChild::_geturl crashes on NULL char*, needs to serialize them

I should note that this only fixes the hang/crasher.  The first stage of the fix *without* NullableString*() helpers in PluginInstanceParent.cpp would display the "Lorem ipsum ..." text.  The second version that added those helpers no longer did.  I'm not sure where the bug there lies, or if it even exists, so ping-ponging it back to those knowledgeable about NPStream.
Closed: 13 years ago
Resolution: --- → FIXED
hrm, I'm not sure I like this solution, but it will do for now. Now to debug the failure...
Can you be more specific?  Any solution to this problem needs to distinguish NULL and "", and hence serialize both, as the two values have different meaning to some NPAPI functions.
Yes, but the notion that XPCOM strings have a special void state is awful and we've been trying to get rid of it for years. Now we're propagating it to new realms.
That's fair, IsVoid seems wonky to me as well.

I'd be all for creating mozilla::plugins::NullableString as a wrapper around nsCString to do what we're abusing nsCString::IsVoid for.
You need to log in before you can comment on or make changes to this bug.