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

Categories

(Core :: Plug-ins, defect)

Unspecified
Windows 10
defect
Not set
critical

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jseward, Unassigned)

Details

(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 https://bugzilla.mozilla.org/show_bug.cgi?id=1449736#c2
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.
Status: NEW → RESOLVED
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.