NULL dereference in LookupNPP after reparenting and reinstantiating plugin

RESOLVED FIXED in mozilla17



5 years ago
5 years ago


(Reporter: johns, Unassigned)



Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)



(2 attachments, 1 obsolete attachment)



5 years ago
Created attachment 645524 [details] [diff] [review]
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

5 years ago
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.


5 years ago
Keywords: regression
OS: Linux → All
Hardware: x86_64 → All
Created attachment 646129 [details] [diff] [review]
Null check private of NPObjWrapper in nsJSObjWrapper::GetNewOrUsed. v1

Not a regression, but still a crash that's worth fixing. Flagging bsmedberg for review.
Attachment #646129 - Flags: review?(benjamin)
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?


5 years ago
Attachment #646129 - Flags: review?(benjamin) → review+
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.

Comment 5

5 years ago
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17

Comment 6

5 years ago
Created attachment 646709 [details] [diff] [review]
Add test
Attachment #645524 - Attachment is obsolete: true

Comment 7

5 years ago
Comment on attachment 646709 [details] [diff] [review]
Add test

Simpler test case. Triggers the crash, passes with the patch
Attachment #646709 - Flags: review?(bobbyholley+bmo)
Comment on attachment 646709 [details] [diff] [review]
Add test

Awesome, thanks for putting this together! r=bholley
Attachment #646709 - Flags: review?(bobbyholley+bmo) → review+

Comment 9

5 years ago
Comment on attachment 646709 [details] [diff] [review]
Add test
Attachment #646709 - Flags: checkin+
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.