Closed Bug 1462997 Opened 4 years ago Closed 3 years ago

Crash in mozilla::ipc::FatalError | mozilla::ipc::IProtocol::HandleFatalError | mozilla::plugins::PPluginInstanceChild::CallNPN_GetValue_NPNVWindowNPObject


(Core :: Plug-ins, defect)

Windows 10
Not set





(Reporter: jseward, Unassigned)


(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is
report bp-6fbe9c1c-3fe9-448d-9d59-421130180519.

This is topcrash #8 in the windows nightly 20180517100441.

Top 10 frames of crashing thread:

0 mozglue.dll MOZ_CrashOOL mfbt/Assertions.cpp:33
1 xul.dll mozilla::ipc::FatalError ipc/glue/ProtocolUtils.cpp:300
2 xul.dll mozilla::ipc::IProtocol::HandleFatalError ipc/glue/ProtocolUtils.cpp:529
3 xul.dll mozilla::plugins::PPluginInstanceChild::CallNPN_GetValue_NPNVWindowNPObject ipc/ipdl/PPluginInstanceChild.cpp:159
4 xul.dll mozilla::plugins::PluginInstanceChild::InternalGetNPObjectForValue dom/plugins/ipc/PluginInstanceChild.cpp:278
5 xul.dll mozilla::plugins::PluginInstanceChild::NPN_GetValue dom/plugins/ipc/PluginInstanceChild.cpp:403
6 xul.dll static short mozilla::plugins::child::_getvalue dom/plugins/ipc/PluginModuleChild.cpp:1123
7 npswf64_29_0_0_140.dll F2086112263____________________________________________________________ F1737606425____________________________________________________________:335
8 npswf64_29_0_0_140.dll NPP_New F17927733___________________________________________________________:678
9 xul.dll mozilla::plugins::PPluginModuleChild::OnMessageReceived ipc/ipdl/PPluginModuleChild.cpp:1006

Flags: needinfo?(cdiehl)
Not sure I can be of much service here.

It seems to be a controlled abort in FatalError() involving "PPluginInstance::Msg_NPN_GetValue_NPNVWindowNPObject".

I see that Faulty has "PPluginModule::Msg_SyncNPP_New" on the blacklist cause of too many fuzz blockers.

May be this crash is similar to "CallNPN_GetValue_NPNVWindowNPObject" in
Flags: needinfo?(cdiehl)
    158     if ((!(ReadIPDLParam((&(reply__)), (&(iter__)), this, value)))) {
    159         FatalError("Error deserializing 'PPluginScriptableObjectChild'");

So it's an actor ID that doesn't map to a live actor.  When there's a fuzzer sending bad IDs deliberately, that makes sense.  In normal operation, that's… not expected.

It looks like the plugin is requesting a proxy for the DOM window object, but when the reply message reaches the plugin process (from the content process), either the constructor message hasn't arrived yet (which shouldn't be possible — it's sent before returning from the Answer method, and I don't see any runnable-sending that could mess up the ordering) or it's already been destroyed.

It's not immediately obvious from looking at the code how the actor would be destroyed (in the sense of Send__delete__) in that window, but the lifetime management for PluginScriptableObject is complex.
Closing because no crash reported since 12 weeks.
Closed: 3 years ago
Resolution: --- → WONTFIX
Closing because no crash reported since 12 weeks.
You need to log in before you can comment on or make changes to this bug.