Last Comment Bug 764480 - bad assertion running test_NPNVdocumentOrigin.html
: bad assertion running test_NPNVdocumentOrigin.html
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla17
Assigned To: John Schoenick [:johns]
:
:
Mentors:
: 765103 (view as bug list)
Depends on:
Blocks: 780969
  Show dependency treegraph
 
Reported: 2012-06-13 10:40 PDT by Josh Aas
Modified: 2012-10-02 13:04 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (397 bytes, text/html)
2012-06-26 15:57 PDT, John Schoenick [:johns]
no flags Details
Don't try to instantiate plugins while not bound to tree (7.61 KB, patch)
2012-07-05 18:48 PDT, John Schoenick [:johns]
jaas: review+
Details | Diff | Splinter Review

Description Josh Aas 2012-06-13 10:40:05 PDT
I was running mochitests locally with a trunk build on Mac OS X and I saw this for test_NPNVdocumentOrigin.html:

###!!! ASSERTION: Shouldn't be calling InstantiatePluginInstance in an inactive document: 'Error', file /Users/josh/src/mozilla/ff_trunk_debug_x86_64/content/base/src/nsObjectLoadingContent.cpp, line 656
nsObjectLoadingContent::InstantiatePluginInstance(char const*, nsIURI*)+0x00000274 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x009C3814]
nsObjectLoadingContent::SyncStartPluginInstance()+0x00000103 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x009CB4E3]
nsAsyncInstantiateEvent::Run()+0x00000054 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x009C0B64]
nsThread::ProcessNextEvent(bool, bool*)+0x00000653 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x02361A33]
NS_ProcessPendingEvents_P(nsIThread*, unsigned int)+0x0000009D [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x022CB0AD]
nsBaseAppShell::NativeEventCallback()+0x000000D1 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x01F33291]
nsAppShell::ProcessGeckoEvents(void*)+0x000001BD [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x01EC851D]
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__+0x00000011 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x000124F1]
__CFRunLoopDoSources0+0x000000FD [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x00011D5D]
__CFRunLoopRun+0x00000389 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x00038B49]
CFRunLoopRunSpecific+0x000000E6 [/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation +0x00038486]
RunCurrentEventLoopInMode+0x00000115 [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x000024D3]
ReceiveNextEventCommon+0x000000B5 [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x000096D3]
BlockUntilNextEventMatchingListInMode+0x0000003E [/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox +0x0000960E]
_DPSNextEvent+0x00000293 [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x00008E31]
-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]+0x00000087 [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x00008735]
-[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]+0x00000077 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x01EC6BF7]
-[NSApplication run]+0x000001D6 [/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit +0x00005071]
nsAppShell::Run()+0x0000008C [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x01EC901C]
nsAppStartup::Run()+0x00000096 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x01B150F6]
XREMain::XRE_mainRun()+0x000016DC [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x0001181C]
XREMain::XRE_main(int, char**, nsXREAppData const*)+0x000002F0 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x00012060]
XRE_main+0x00000046 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x000124B6]
_ZL7do_mainiPPc+0x000003B7 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/firefox-bin +0x00001B87]
main+0x000002C9 [/Users/josh/src/mozilla/ff_trunk_debug_x86_64/obj-x86_64-apple-darwin11.4.0/dist/NightlyDebug.app/Contents/MacOS/firefox-bin +0x00001459]
Comment 1 Josh Aas 2012-06-13 19:44:32 PDT
My theory... The test ("test_NPNVdocumentOrigin.html") runs quite quickly and instantiates a plugin late. In the process of instantiating the plugin we create extra (unnecessary) async instantiation events and one of them is getting run after the plugin has already instantiated successfully and the test finished. So the document is inactive because the test is done, yet we still have an outstanding async instantiate event.

John Schoenick is planning to resolve the issue with the extra async instantiate events as part of his efforts in bug 745030. Assigning this to him.
Comment 2 John Schoenick [:johns] 2012-06-26 15:57:57 PDT
Created attachment 636916 [details]
testcase
Comment 3 John Schoenick [:johns] 2012-07-05 17:38:30 PDT
*** Bug 765103 has been marked as a duplicate of this bug. ***
Comment 4 John Schoenick [:johns] 2012-07-05 18:48:35 PDT
Created attachment 639553 [details] [diff] [review]
Don't try to instantiate plugins while not bound to tree

Fixes a few cases where we can reach instantiation when not in an active document. We were previously checking IsInDoc() and OwnerDoc()->IsActive() in several places, but rarely both...
Comment 5 John Schoenick [:johns] 2012-07-05 18:49:28 PDT
I should note, this lands on top of bug 745030
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2012-08-07 16:32:47 PDT
That doesn't look right to me at first glance.  Shouldn't the following work?

 var obj = document.createElement("object");
 obj.data = "some.gif"
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2012-08-07 16:34:29 PDT
Hmm.  I guess it didn't use to before the refactoring either....
Comment 8 John Schoenick [:johns] 2012-08-07 17:03:11 PDT
(In reply to Boris Zbarsky (:bz) [In and out Aug 1 - 10, out Aug 11-20] from comment #6)
> That doesn't look right to me at first glance.  Shouldn't the following work?
> 
>  var obj = document.createElement("object");
>  obj.data = "some.gif"

What do you mean by work, in this case? nsHTMLObjectElement will fire LoadObject() after it binds to the tree.

If you mean it should immediately begin loading the resource prior to being in-doc, that has never worked. In the case of plugins, it shouldn't/can't load; I'm not sure if it's desirable in other cases.
Comment 9 John Schoenick [:johns] 2012-08-07 17:04:57 PDT
(In reply to John Schoenick [:johns] from comment #8)
> If you mean it should immediately begin loading the resource prior to being
> in-doc, that has never worked. In the case of plugins, it shouldn't/can't
> load; I'm not sure if it's desirable in other cases.

Note that with the refactoring, I don't think there's anything from stopping us from adding | || mType != eType_Plugin | to a few spots in-doc-check spots to obtain this behavior, however
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2012-08-07 17:08:47 PDT
> If you mean it should immediately begin loading the resource prior to being in-doc

That's what I meant (for the non-plugin cases), but you're right that it never worked before, indeed.
Comment 11 :Ms2ger (⌚ UTC+1/+2) 2012-08-09 14:02:58 PDT
Comment on attachment 639553 [details] [diff] [review]
Don't try to instantiate plugins while not bound to tree

Review of attachment 639553 [details] [diff] [review]:
-----------------------------------------------------------------

::: content/base/src/nsObjectLoadingContent.cpp
@@ +101,5 @@
> +  if (!aContent->IsInDoc()) {
> +    return false;
> +  }
> +  nsIDocument *doc = aContent->OwnerDoc();
> +  return (doc && doc->IsActive());

This null check is pointless; as its name indicates, OwnerDoc() never returns null.
Comment 13 Ryan VanderMeulen [:RyanVM] 2012-08-09 19:56:34 PDT
https://hg.mozilla.org/mozilla-central/rev/c20b340b1922
Comment 14 neil@parkwaycc.co.uk 2012-10-02 03:51:31 PDT
Comment on attachment 639553 [details] [diff] [review]
Don't try to instantiate plugins while not bound to tree

>+  // Sanity check
>+  if (!InActiveDocument(thisContent)) {
>+    NS_NOTREACHED("LoadObject called while not bound to an active document");
>+    return NS_ERROR_UNEXPECTED;
>+  }
So, I hit this while browsing. If I hit it again, should I file a bug? If so, what information would you like me to capture? Unfortunately all I can remember is that HttpAsyncAborter was on the stack.
Comment 15 Jesse Ruderman 2012-10-02 13:04:58 PDT
Or you could wait for bug 791524 to be fixed and see if the fuzzer hits it again.

Note You need to log in before you can comment on or make changes to this bug.