Last Comment Bug 557127 - [Debug SeaMonkey 2.1] mochitest-plain-5: "test_feed_discovery.html | Test timed out.", caused by "ASSERTION: Implicit native wrapper in content code"
: [Debug SeaMonkey 2.1] mochitest-plain-5: "test_feed_discovery.html | Test tim...
Status: VERIFIED FIXED
: assertion
Product: SeaMonkey
Classification: Client Software
Component: Feed Discovery and Preview (show other bugs)
: Trunk
: All All
: -- major (vote)
: seamonkey2.1a1
Assigned To: neil@parkwaycc.co.uk
:
Mentors:
http://mxr.mozilla.org/mozilla-centra...
Depends on: 484187
Blocks: SmTestFail 524994
  Show dependency treegraph
 
Reported: 2010-04-04 11:58 PDT by Serge Gautherie (:sgautherie)
Modified: 2010-04-29 02:58 PDT (History)
4 users (show)
bugzillamozillaorg_serge_20140323: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Workaround (518 bytes, patch)
2010-04-25 12:05 PDT, neil@parkwaycc.co.uk
bugspam.Callek: review+
Details | Diff | Review

Description Serge Gautherie (:sgautherie) 2010-04-04 11:58:39 PDT
{
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1270400146.1270402034.14631.gz&fulltext=1
WINNT 5.2 comm-central-trunk debug test mochitests-5/5 on 2010/04/04 09:55:46

###!!! ASSERTION: Implicit native wrapper in content code: 'Error', file e:/builds/slave/comm-central-trunk-win32-debug/build/mozilla/js/src/xpconnect/src/XPCNativeWrapper.cpp, line 436
xpc3250!DumpJSValue+0x0000000000075167
xpc3250!DumpJSValue+0x00000000000750B3
mozjs!JS_NewArrayObject+0x00000000000B95DA
mozjs!JS_NewArrayObject+0x00000000000B91AA
mozjs!JS_NewArrayObject+0x00000000000BA154
mozjs!JS_NewArrayObject+0x000000000008C4AE
mozjs!JS_NewArrayObject+0x000000000007D577
mozjs!JS_NewArrayObject+0x000000000007E0FB
mozjs!JS_NewArrayObject+0x0000000000022036
gklayout!NSGetModule+0x00000000004BC6C7
gklayout!NSGetModule+0x0000000000521B58
gklayout!NSGetModule+0x000000000035E83E
gklayout!NSGetModule+0x000000000035ECA4
gklayout!NSGetModule+0x0000000000363524
gklayout!NSGetModule+0x0000000000363205
gklayout!NSGetModule+0x0000000000363EB1
gklayout!NSGetModule+0x000000000003356C
docshell!mozilla::fallible_t::operator=+0x00000000000178D2
docshell!mozilla::fallible_t::operator=+0x000000000001745D
docshell!mozilla::fallible_t::operator=+0x0000000000051048
docshell!mozilla::fallible_t::operator=+0x00000000000501CA
docshell!mozilla::fallible_t::operator=+0x000000000004FDE3
docshell!mozilla::fallible_t::operator=+0x000000000004FA5F
necko!NSGetModule+0x000000000002F5ED
gklayout!NSGetModule+0x000000000029D459
gklayout!NSGetModule+0x000000000029D202
gklayout!NSGetModule+0x000000000029456D
gklayout!NSGetModule+0x00000000002A2CDE
xpcom_core!nsEventQueue::PutEvent+0x0000000000007F3A
xpcom_core!nsCOMPtr_base::assign_with_AddRef+0x0000000000014DC2
gkwidget!NSGetModule+0x000000000005DEE1
gkwidget!NSGetModule+0x0000000000008D96
toolkitcomps!mozilla::fallible_t::operator=+0x000000000000D942
xul!XRE_main+0x00000000000032B2
seamonkey!mozilla::fallible_t::operator=+0x00000000000012C3
seamonkey!mozilla::fallible_t::operator=+0x0000000000000C02
seamonkey!mozilla::fallible_t::operator=+0x0000000000001EDA
seamonkey!mozilla::fallible_t::operator=+0x0000000000001D31
kernel32!ProcessIdToSessionId+0x0000000000000209
}

The test
http://mxr.mozilla.org/comm-central/source/suite/browser/test/mochitest/test_feed_discovery.html?force=1
Comment 1 Serge Gautherie (:sgautherie) 2010-04-25 08:35:54 PDT
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a5pre) Gecko/20100421 SeaMonkey/2.1a1pre] (comm-central-trunk-win32/1271913096)

Test passes (locally) with Optimized build:
{
Passed: 26
Failed: 0
Todo: 1
passed | some feeds should be discovered
passed | should discover http://mochi.test:8888/1.atom
passed | should discover http://mochi.test:8888/2.rss
passed | should discover http://mochi.test:8888/3.xml
passed | should discover http://mochi.test:8888/4.atom
passed | should discover http://mochi.test:8888/5.atom
passed | should discover http://mochi.test:8888/6.atom
passed | should discover http://mochi.test:8888/7.atom
passed | should discover http://mochi.test:8888/8.atom
passed | should discover http://mochi.test:8888/9.atom
passed | should discover http://mochi.test:8888/10.atom
todo | should discover http://mochi.test:8888/11.atom
}
Comment 2 Serge Gautherie (:sgautherie) 2010-04-25 08:47:44 PDT
The assertion happens before (or during) the first check.

Better stack report:

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1272198079.1272200118.13789.gz&fulltext=1
WINNT 5.2 comm-central-trunk debug test mochitests-5/5 on 2010/04/25 05:21:19
{
###!!! ASSERTION: Implicit native wrapper in content code: 'Error', file e:/builds/slave/comm-central-trunk-win32-debug/build/mozilla/js/src/xpconnect/src/XPCNativeWrapper.cpp, line 462
xpc3250!XPC_NW_GetOrSetProperty+0x000000000000009E (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\xpconnect\src\xpcnativewrapper.cpp, line 621)
xpc3250!XPC_NW_GetProperty+0x000000000000001A (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\xpconnect\src\xpcnativewrapper.cpp, line 663)
mozjs!JSScopeProperty::get+0x000000000000019C (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\jsscope.h, line 1006)
mozjs!js_NativeGet+0x0000000000000190 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\jsobj.cpp, line 4703)
mozjs!js_GetPropertyHelper+0x0000000000000340 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\jsobj.cpp, line 4875)
mozjs!js_Interpret+0x000000000000A3CE (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\jsops.cpp, line 1490)
mozjs!js_Invoke+0x000000000000087C (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\jsinterp.cpp, line 842)
mozjs!js_InternalInvoke+0x0000000000000082 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\jsinterp.cpp, line 899)
mozjs!JS_CallFunctionValue+0x000000000000005D (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\jsapi.cpp, line 4945)
gklayout!nsJSContext::CallEventHandler+0x0000000000000316 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\dom\base\nsjsenvironment.cpp, line 2163)
gklayout!nsJSEventListener::HandleEvent+0x0000000000000BBE (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\dom\src\events\nsjseventlistener.cpp, line 228)
gklayout!nsEventListenerManager::HandleEventSubType+0x00000000000002E4 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\content\events\src\nseventlistenermanager.cpp, line 1082)
gklayout!nsEventListenerManager::HandleEventInternal+0x000000000000031D (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\content\events\src\nseventlistenermanager.cpp, line 1180)
gklayout!nsEventListenerManager::HandleEvent+0x00000000000000D5 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\content\events\src\nseventlistenermanager.h, line 145)
gklayout!nsEventTargetChainItem::HandleEvent+0x0000000000000120 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\content\events\src\nseventdispatcher.cpp, line 212)
gklayout!nsEventTargetChainItem::HandleEventTargetChain+0x000000000000019B (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\content\events\src\nseventdispatcher.cpp, line 342)
gklayout!nsEventDispatcher::Dispatch+0x000000000000083F (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\content\events\src\nseventdispatcher.cpp, line 620)
gklayout!DocumentViewerImpl::LoadComplete+0x00000000000001F2 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\layout\base\nsdocumentviewer.cpp, line 1027)
docshell!nsDocShell::EndPageLoad+0x00000000000001A3 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\docshell\base\nsdocshell.cpp, line 5755)
docshell!nsDocShell::OnStateChange+0x000000000000044E (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\docshell\base\nsdocshell.cpp, line 5633)
docshell!nsDocLoader::FireOnStateChange+0x00000000000001F9 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\uriloader\base\nsdocloader.cpp, line 1318)
docshell!nsDocLoader::doStopDocumentLoad+0x000000000000008B (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\uriloader\base\nsdocloader.cpp, line 940)
docshell!nsDocLoader::DocLoaderIsEmpty+0x000000000000025A (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\uriloader\base\nsdocloader.cpp, line 807)
docshell!nsDocLoader::OnStopRequest+0x00000000000003B0 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\uriloader\base\nsdocloader.cpp, line 703)
necko!nsLoadGroup::RemoveRequest+0x0000000000000243 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\netwerk\base\src\nsloadgroup.cpp, line 680)
gklayout!nsDocument::DoUnblockOnload+0x00000000000000EF (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\Document http://mochi.test:8888/tests/suite/browser/test/feed_discovery.html loaded successfully
}
Comment 3 Serge Gautherie (:sgautherie) 2010-04-25 08:52:41 PDT
Fwiw, apart from the "todo" case and support, the (only) test code difference between FF and SM is:

http://mxr.mozilla.org/comm-central/find?text=&string=feed_discovery.html
FF has
83         var browser = currentWindow.gBrowser.selectedBrowser;
85         var discovered = browser.feeds;
SM has
83         var browserSH = currentWindow.XULBrowserWindow;
85         var discovered = browserSH.feeds;
Comment 4 Serge Gautherie (:sgautherie) 2010-04-25 09:04:41 PDT
(In reply to comment #3)

PS: SM is also still using MochiKit.js instead of packed.js, fwiw.
Comment 5 Robert Kaiser (not working on stability any more) 2010-04-25 09:08:25 PDT
Does changing those two things from comment #3 and comment #4 change something? Or are you still not able to run the debug builds/tests?

The comment #4 case is probably true for multiple tests in suite/ and it's probably a good idea to file an extra bug to fix this across all tests (putting a reference in that bug of where this changed in FF is probably helpful as well). I'd be more than willing to r+ such a patch there.
Comment 6 Serge Gautherie (:sgautherie) 2010-04-25 09:34:37 PDT
(In reply to comment #5)

> Or are you still not able to run the debug builds/tests?

Bug 557060 is not fixed yet for c-c...

> The comment #4 case is probably true for multiple tests in suite/ and it's
> probably a good idea to file an extra bug to fix this across all tests

I did link bug 490955 to FF2SM...
Comment 7 Robert Kaiser (not working on stability any more) 2010-04-25 09:45:50 PDT
(In reply to comment #6)
> (In reply to comment #5)
> 
> > Or are you still not able to run the debug builds/tests?
> 
> Bug 557060 is not fixed yet for c-c...

Hrm, bad, we really should get that done!

> > The comment #4 case is probably true for multiple tests in suite/ and it's
> > probably a good idea to file an extra bug to fix this across all tests
> 
> I did link bug 490955 to FF2SM...

Ah, a first step, good. Unfortunately, the FF2SM/TB2SM bugs are a bit of a mess as it's not easy to see a) what is a bug from the others we need to still file a bug on our side on, b) what is an open bug on our side to port something, and c) what is a fixed porting bug on our side. Of course, that can be found, but it's too hard. I hope custom bug relations coming up in a future Bugzilla update should help with that.
Comment 8 Serge Gautherie (:sgautherie) 2010-04-25 10:08:15 PDT
(In reply to comment #7)

> > Bug 557060 is not fixed yet for c-c...
> 
> Hrm, bad, we really should get that done!

I can only wait for the end of the TB 3.1b2 freeze...
(Though I may still be unable to run debug mochitests: to be investigated at that time.)

> the FF2SM/TB2SM bugs are a bit of a mess
> as it's not easy to see a) what is a bug from the others we need to still file
> a bug on our side on, b) what is an open bug on our side to port something, and
> c) what is a fixed porting bug on our side.

I fully agree, but that's what we have atm.
Maybe a- and b- could be split to new meta-bugs, if that would help.
c- bugs should(...) just be unlinked. (Issue would disappear with a separate b-...)
Comment 9 neil@parkwaycc.co.uk 2010-04-25 11:45:57 PDT
OK, so what's going on here is that our XULBrowserWindow stores the list of <link> elements in its feeds array. And because it's chrome code that's doing the storing, it's storing XPCNativeWrappers of the elements, rather than the elements themselves. Now when the mochitest comes along and tries to retrieve the wrapped elements, XPConnect is stepping in and denying access. Oops.
Comment 10 neil@parkwaycc.co.uk 2010-04-25 12:05:52 PDT
Created attachment 441385 [details] [diff] [review]
Workaround

By forcing XPConnect to unwrap the wrapper, we can then access the element.

This doesn't affect Firefox because they create a JavaScript shallow "clone" of the element instead of using the original element.
Comment 11 neil@parkwaycc.co.uk 2010-04-28 16:33:24 PDT
Pushed changeset cbb67232177d to comm-central.
Comment 12 Serge Gautherie (:sgautherie) 2010-04-28 16:54:06 PDT
(In reply to comment #11)
> Pushed changeset cbb67232177d to comm-central.

"Bug 551727 Work around bogus XPConnect assertion r=Callek irc-f=mrbkap"

*Ftr, s/551727/557127/.
*Does this comment implies that a bug should be filed against XPConnect?
Comment 13 Serge Gautherie (:sgautherie) 2010-04-28 19:32:40 PDT
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1272503105.1272503858.5766.gz
OS X 10.5 comm-central-trunk debug test mochitests-5/5 on 2010/04/28 18:05:05

(In reply to comment #1)

Now, the test runs fully (== up to "don't discover http://mochi.test:8888/Bogus13") :-)

V.Fixed

***

Somehow, fixing this failure fixed the 3 test_radio.xul ones and the test_tooltip.xul one too :->

Windows had the 3 test_radio.xul ones too: hopefully, they'll be fixed too.
(I couldn't reproduce them on my local Win2K with an optimized build when I checked them.)
Comment 14 neil@parkwaycc.co.uk 2010-04-29 02:58:39 PDT
(In reply to comment #12)
> "Bug 551727 Work around bogus XPConnect assertion r=Callek irc-f=mrbkap"
> 
> *Ftr, s/551727/557127/.
Oops.

> *Does this comment implies that a bug should be filed against XPConnect?
mrbkap mentioned a bug to me last night (I can't remember it offhand).

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