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

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect)

Description

[Julian Seward [:jseward]]

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

=============================================================

Comment 1

[Christoph Diehl [:posidron]]

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

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-8⟩ ⟦he/him⟧]

    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.

Comment 3

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.

Comment 4

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.