Closed
Bug 777098
Opened 12 years ago
Closed 12 years ago
NULL dereference in LookupNPP after reparenting and reinstantiating plugin
Categories
(Core :: XPConnect, defect)
Core
XPConnect
Tracking
()
RESOLVED
FIXED
mozilla17
People
(Reporter: johns, Unassigned)
References
Details
(Keywords: crash)
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
bholley
:
review+
johns
:
checkin+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•12 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.
Reporter | ||
Updated•12 years ago
|
Comment 2•12 years ago
|
||
Not a regression, but still a crash that's worth fixing. Flagging bsmedberg for review.
Attachment #646129 -
Flags: review?(benjamin)
Comment 3•12 years ago
|
||
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?
Updated•12 years ago
|
Attachment #646129 -
Flags: review?(benjamin) → review+
Comment 4•12 years ago
|
||
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•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/e3b08a3c9bd7
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Reporter | ||
Comment 7•12 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 8•12 years ago
|
||
Comment on attachment 646709 [details] [diff] [review] Add test Awesome, thanks for putting this together! r=bholley
Attachment #646709 -
Flags: review?(bobbyholley+bmo) → review+
Reporter | ||
Comment 9•12 years ago
|
||
Comment on attachment 646709 [details] [diff] [review] Add test https://hg.mozilla.org/integration/mozilla-inbound/rev/1792c68aef95
Attachment #646709 -
Flags: checkin+
Updated•12 years ago
|
Flags: in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•