bad assertion running test_NPNVdocumentOrigin.html

RESOLVED FIXED in mozilla17

Status

()

Core
Plug-ins
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Josh Aas, Assigned: johns)

Tracking

Trunk
mozilla17
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
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]
(Reporter)

Comment 1

5 years ago
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.
Assignee: joshmoz → jschoenick
(Assignee)

Updated

5 years ago
Status: NEW → ASSIGNED
Depends on: 767635
OS: Mac OS X → All
(Assignee)

Comment 2

5 years ago
Created attachment 636916 [details]
testcase
(Assignee)

Updated

5 years ago
Duplicate of this bug: 765103
(Assignee)

Comment 4

5 years ago
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...
Attachment #639553 - Flags: review?(joshmoz)
(Assignee)

Comment 5

5 years ago
I should note, this lands on top of bug 745030
(Reporter)

Updated

5 years ago
Attachment #639553 - Flags: review?(joshmoz) → review+
(Assignee)

Updated

5 years ago
No longer depends on: 767635
(Assignee)

Updated

5 years ago
Blocks: 780969
That doesn't look right to me at first glance.  Shouldn't the following work?

 var obj = document.createElement("object");
 obj.data = "some.gif"
Hmm.  I guess it didn't use to before the refactoring either....
(Assignee)

Comment 8

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

Comment 9

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

Comment 12

5 years ago
Survived try:
https://tbpl.mozilla.org/?tree=Try&rev=02f602af452c

Pushed to m-i:
http://hg.mozilla.org/integration/mozilla-inbound/rev/c20b340b1922
https://hg.mozilla.org/mozilla-central/rev/c20b340b1922
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
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

5 years ago
Or you could wait for bug 791524 to be fixed and see if the fuzzer hits it again.
You need to log in before you can comment on or make changes to this bug.