777098 - NULL dereference in LookupNPP after reparenting and reinstantiating plugin

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[John Schoenick [:johns]]

Attachment: Tweak test_bug771202.html to trigger crash

After bug 771202, it seems reparenting a plugin as it is re-instantiating results in bad times all around. With the attached tweak to the plugin-proto mochitest, we run into this crash

Also note that reparenting a plugin may cause the plugin to re-instantiate as valid behavior (such as, the plugin has a relative URI, which changes when moving between documents), though my tweak here just forces a re-instantiation.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff3be1517 in LookupNPP (npobj=0x0) at /home/johns/moz/moz-git/dom/plugins/base/nsJSNPRuntime.cpp:2095
2095      if (npobj->_class == &nsJSObjWrapper::sJSObjWrapperNPClass) {
(gdb) bt
#0  0x00007ffff3be1517 in LookupNPP (npobj=0x0) at /home/johns/moz/moz-git/dom/plugins/base/nsJSNPRuntime.cpp:2095
#1  0x00007ffff3be042b in nsJSObjWrapper::GetNewOrUsed (npp=0x7fffc7cff7f8, cx=0x7fffd62122b0, obj=0x7fffdfc76490)
    at /home/johns/moz/moz-git/dom/plugins/base/nsJSNPRuntime.cpp:1072
#2  0x00007ffff3bdff2c in JSValToNPVariant (npp=0x7fffc7cff7f8, cx=0x7fffd62122b0, val=..., variant=0x7fffffff85c0)
    at /home/johns/moz/moz-git/dom/plugins/base/nsJSNPRuntime.cpp:490
#3  0x00007ffff3be3c76 in CallNPMethodInternal (cx=0x7fffd62122b0, obj=0x7fffdfc6e2e0, argc=1, argv=0x7fffe0eff1a0, rval=0x7fffe0eff190, ctorCall=false)
    at /home/johns/moz/moz-git/dom/plugins/base/nsJSNPRuntime.cpp:1445
#4  0x00007ffff3be44a2 in CallNPMethod (cx=0x7fffd62122b0, argc=1, vp=0x7fffe0eff190) at /home/johns/moz/moz-git/dom/plugins/base/nsJSNPRuntime.cpp:1537
#5  0x00007ffff4dcf8aa in js::CallJSNative (cx=0x7fffd62122b0, native=0x7ffff3be4430 <CallNPMethod(JSContext*, unsigned int, JS::Value*)>, args=...)
    at /home/johns/moz/moz-git/js/src/jscntxtinlines.h:382
#6  0x00007ffff4dcf3cd in js::InvokeKernel (cx=0x7fffd62122b0, args=..., construct=js::NO_CONSTRUCT) at /home/johns/moz/moz-git/js/src/jsinterp.cpp:345
#7  0x00007ffff4dc36a7 in js::Interpret (cx=0x7fffd62122b0, entryFrame=0x7fffe0eff0a0, interpMode=js::JSINTERP_NORMAL)
    at /home/johns/moz/moz-git/js/src/jsinterp.cpp:2426
#8  0x00007ffff4db6f78 in js::RunScript (cx=0x7fffd62122b0, script=0x7fffdfc672e0, fp=0x7fffe0eff0a0) at /home/johns/moz/moz-git/js/src/jsinterp.cpp:302
#9  0x00007ffff4dcf497 in js::InvokeKernel (cx=0x7fffd62122b0, args=..., construct=js::NO_CONSTRUCT) at /home/johns/moz/moz-git/js/src/jsinterp.cpp:356
#10 0x00007ffff4cfb773 in js::Invoke (cx=0x7fffd62122b0, args=..., construct=js::NO_CONSTRUCT) at /home/johns/moz/moz-git/js/src/jsinterp.h:119
#11 0x00007ffff4dcfc97 in js::Invoke (cx=0x7fffd62122b0, thisv=..., fval=..., argc=0, argv=0x0, rval=0x7fffffffae20)
    at /home/johns/moz/moz-git/js/src/jsinterp.cpp:388
#12 0x00007ffff4cd3038 in JS_CallFunctionValue (cx=0x7fffd62122b0, obj=0x7fffdfc63060, fval=..., argc=0, argv=0x0, rval=0x7fffffffae20)
    at /home/johns/moz/moz-git/js/src/jsapi.cpp:5566
#13 0x00007ffff2f133fa in nsJSContext::CallEventHandler (this=0x7fffd596fe80, aTarget=0x7fffcff6a800, aScope=0x7fffdfc63060, aHandler=0x7fffdfc9dc00, aargv=
    0x7fffc8cff040, arv=0x7fffffffafd8) at /home/johns/moz/moz-git/dom/base/nsJSEnvironment.cpp:1907

Comment 1

[John Schoenick [:johns]]

This appears to happen even before bug 771202, and per conversation with bholley, is just a missing null check. Wrapped plugin objects can survive their actual plugins, and then be passed to another plugin, at which point this occurs.

Comment 2

[Bobby Holley (:bholley)]

Attachment: Null check private of NPObjWrapper in nsJSObjWrapper::GetNewOrUsed. v1

Not a regression, but still a crash that's worth fixing. Flagging bsmedberg for review.

Comment 3

[Bobby Holley (:bholley)]

John, this fixes the testcase, but I don't want to check in a testcase that uses setTimeout with a non-zero timeout. Can you come up with a better crashtest? Is there a way to be notified when the plugin is re-instantiated?

Comment 4

[Bobby Holley (:bholley)]

Would be nice to get some test coverage on this bug, but I'm going to push the fix in the mean time given that it's just a null check.

http://hg.mozilla.org/integration/mozilla-inbound/rev/e3b08a3c9bd7

Comment 5

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/e3b08a3c9bd7

Comment 6

[John Schoenick [:johns]]

Attachment: Add test

Comment 7

[John Schoenick [:johns]]

Comment on attachment 646709 [details] [diff] [review]
Add test

Simpler test case. Triggers the crash, passes with the patch

Comment 8

[Bobby Holley (:bholley)]

Comment on attachment 646709 [details] [diff] [review]
Add test

Awesome, thanks for putting this together! r=bholley

Comment 9

[John Schoenick [:johns]]

Comment on attachment 646709 [details] [diff] [review]
Add test

https://hg.mozilla.org/integration/mozilla-inbound/rev/1792c68aef95

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/1792c68aef95