As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact bugzilla-admin@mozilla.org
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]
:
: Benjamin Smedberg [:bsmedberg]
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 User image 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 User image 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 User image John Schoenick [:johns] 2012-06-26 15:57:57 PDT
Created attachment 636916 [details]
testcase
Comment 3 User image John Schoenick [:johns] 2012-07-05 17:38:30 PDT
*** Bug 765103 has been marked as a duplicate of this bug. ***
Comment 4 User image 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 User image John Schoenick [:johns] 2012-07-05 18:49:28 PDT
I should note, this lands on top of bug 745030
Comment 6 User image 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 User image 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 User image 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 User image 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 User image 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 User image :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 User image Ryan VanderMeulen [:RyanVM] 2012-08-09 19:56:34 PDT
https://hg.mozilla.org/mozilla-central/rev/c20b340b1922
Comment 14 User image 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 User image 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.