Closed
Bug 557127
Opened 14 years ago
Closed 14 years ago
[Debug SeaMonkey 2.1] mochitest-plain-5: "test_feed_discovery.html | Test timed out.", caused by "ASSERTION: Implicit native wrapper in content code"
Categories
(SeaMonkey :: Feed Discovery and Preview, defect)
SeaMonkey
Feed Discovery and Preview
Tracking
(Not tracked)
VERIFIED
FIXED
seamonkey2.1a1
People
(Reporter: sgautherie, Assigned: neil)
References
(Blocks 1 open bug, )
Details
(Keywords: assertion)
Attachments
(1 file)
518 bytes,
patch
|
Callek
:
review+
|
Details | Diff | Splinter Review |
{ 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
Reporter | ||
Updated•14 years ago
|
Summary: [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 timed out.", caused by "ASSERTION: Implicit native wrapper in content code"
Reporter | ||
Comment 1•14 years ago
|
||
[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 }
Reporter | ||
Comment 2•14 years ago
|
||
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 }
Reporter | ||
Comment 3•14 years ago
|
||
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;
Reporter | ||
Comment 4•14 years ago
|
||
(In reply to comment #3) PS: SM is also still using MochiKit.js instead of packed.js, fwiw.
![]() |
||
Comment 5•14 years ago
|
||
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.
Reporter | ||
Comment 6•14 years ago
|
||
(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•14 years ago
|
||
(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.
Reporter | ||
Comment 8•14 years ago
|
||
(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-...)
Assignee | ||
Comment 9•14 years ago
|
||
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.
Assignee | ||
Comment 10•14 years ago
|
||
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.
Updated•14 years ago
|
Attachment #441385 -
Flags: review?(bugspam.Callek) → review+
Assignee | ||
Comment 11•14 years ago
|
||
Pushed changeset cbb67232177d to comm-central.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 12•14 years ago
|
||
(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?
Component: XPConnect → Feed Discovery and Preview
Flags: in-testsuite+
Product: Core → SeaMonkey
QA Contact: xpconnect → feed.handling
Target Milestone: --- → seamonkey2.1a1
Reporter | ||
Comment 13•14 years ago
|
||
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.)
Status: RESOLVED → VERIFIED
blocking2.0: ? → ---
Assignee | ||
Comment 14•14 years ago
|
||
(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).
You need to log in
before you can comment on or make changes to this bug.
Description
•