Closed Bug 627417 Opened 9 years ago Closed 9 years ago

mochitests-4: permanent "TEST-UNEXPECTED-FAIL | /tests/js/src/xpconnect/tests/mochitest/test_bug384632.html" due to assertion and js_error in (nsSidebar.js) RDF. (crashtest: 244933-1.html too)

Categories

(SeaMonkey :: Build Config, defect, major)

defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED
seamonkey2.1b2

People

(Reporter: sgautherie, Assigned: sgautherie)

References

(Blocks 1 open bug, )

Details

(Keywords: assertion, regression, Whiteboard: [perma-orange])

Attachments

(1 file, 2 obsolete files)

(This started during/after the SeaMonkey omnijar landing bustage,
so I'm not sure which changeset caused this...)

Last green run was:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1295368793.1295374287.32016.gz
Linux comm-central-trunk debug test mochitests-4/5 on 2011/01/18 08:39:53
rev:476b91f50827
moz:141d92d974b4

First failure is:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1295463894.1295469326.27005.gz&fulltext=1
Linux comm-central-trunk debug test mochitests-4/5 on 2011/01/19 11:04:54
rev:44bfbaecd266
moz:94271581b601
{
64 INFO TEST-START | /tests/js/src/xpconnect/tests/mochitest/test_bug384632.html
65 INFO TEST-PASS | /tests/js/src/xpconnect/tests/mochitest/test_bug384632.html | getUserData works with regular objects
###!!! ASSERTION: null ptr: 'aURI != nsnull', file /builds/slave/comm-cen-trunk-lnx-dbg/build/mozilla/rdf/base/src/nsRDFService.cpp, line 1416
RDFServiceImpl::GetDataSource [rdf/base/src/nsRDFService.cpp:1417]
RDFServiceImpl::GetDataSource [rdf/base/src/nsRDFService.cpp:1404]
invoke_copy_to_stack [xpcom/reflect/xptcall/src/md/unix/xptcinvoke_gcc_x86_unix.cpp:69]
...
66 ERROR TEST-UNEXPECTED-FAIL | /tests/js/src/xpconnect/tests/mochitest/test_bug384632.html | [SimpleTest/SimpleTest.js, window.onerror] An error occurred - uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFService.GetDataSource]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: resource://gre/components/nsSidebar.js :: nsSidebar :: line 86"  data: no] at :0
JavaScript error: , line 0: uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFService.GetDataSource]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: resource://gre/components/nsSidebar.js :: nsSidebar :: line 86"  data: no]
67 INFO TEST-END | /tests/js/src/xpconnect/tests/mochitest/test_bug384632.html | finished in 1575ms
}
blocking-seamonkey2.1: --- → ?
Keywords: assertion
MacOSX:

Last greens:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1295372910.1295376822.14908.gz
OS X 10.5 comm-central-trunk debug test mochitests-4/5 on 2011/01/18 09:48:30
rev:41d190c0d35f
moz:8fdde63f610e
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1295372344.1295375950.9040.gz
OS X 10.6 comm-central-trunk debug test mochitests-4/5 on 2011/01/18 09:39:04
rev:41d190c0d35f
moz:a1aacf3854ea

First failures:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1295458048.1295461860.25429.gz
OS X 10.5 comm-central-trunk debug test mochitests-4/5 on 2011/01/19 09:27:28
rev:44bfbaecd266
moz:94271581b601
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1295452884.1295456426.1545.gz
OS X 10.6 comm-central-trunk debug test mochitests-4/5 on 2011/01/19 08:01:24
rev:e9f62190bdf0
moz:37e85354ebaf

***

Windows:

Last green:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1295374403.1295376975.15925.gz
WINNT 5.2 comm-central-trunk debug test mochitests-4/5 on 2011/01/18 10:13:23
rev:476b91f50827
moz:141d92d974b4

First failure:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1295463650.1295467615.19342.gz
WINNT 5.2 comm-central-trunk debug test mochitests-4/5 on 2011/01/19 11:00:50
rev:e9f62190bdf0
moz:844b898f5bc4
Regression timeframes:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a1aacf3854ea&tochange=844b898f5bc4
Many changesets, including a tracemonkey landing...

http://hg.mozilla.org/comm-central/pushloghtml?fromchange=41d190c0d35f&tochange=e9f62190bdf0
Either (browser-places) bug 620066 + bug 620068 or (omnijar) bug 588067.
(Unlikely to be (zoom) bug 624718.)

KaiRo, can you check your c-c changesets?
Blocks: 628079
JavaScript error: , line 0: uncaught exception: [Exception... "Component
returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER)
[nsIRDFService.GetDataSource]"  nsresult: "0x80004003
(NS_ERROR_INVALID_POINTER)"  location: "JS frame ::
resource://gre/components/nsSidebar.js :: nsSidebar :: line 86"  data: no]

http://hg.mozilla.org/comm-central/file/2e8f93800bce/suite/common/src/nsSidebar.js#85

Do we have a valid panels.rdf file here or is the test looking at the wrong location?
Blake, the test case from Bug 384632 has been failing since we switched to omnijar. Do you have any idea what's going wrong?
The only reason the test case is failing is that Blake chose at random the sidebar object at random as a suitable item to test that bug. I think our sidebar object is failing at the initiation step since omnijar because the default panels.rdf can't be copied to the test profile.

> +++ b/suite/locales/Makefile.in
> +NON_OMNIJAR_FILES = defaults/messenger/mailViews.dat
> +

Can someone try adding defaults/profile/panels.rdf to NON_OMNIJAR_FILES as a immediate band aid.

Otherwise someone needs to find out how Firefox deals with the files in their omnijar!/defaults/profile/
Blocks: 588067
No longer blocks: 628079
(In reply to comment #5)
> Otherwise someone needs to find out how Firefox deals with the files in their
> omnijar!/defaults/profile/
As I recall they have code (possibly #ifdef MOZ_OMNIJAR) that looks for the file in omni.jar if it can't find it in its previous location.
(In reply to comment #6)
> (In reply to comment #5)
> > Otherwise someone needs to find out how Firefox deals with the files in their
> > omnijar!/defaults/profile/
> As I recall they have code (possibly #ifdef MOZ_OMNIJAR) that looks for the
> file in omni.jar if it can't find it in its previous location.

Well, not for panels.rdf, as they don't have something like that. Even SeaMonkey should get rid of this legacy one time, but for 2.1, I think it's too late in the game for something like that. Let's just add it to NON_OMNIJAR_FILES, that should fix this problem.
Error Console reports the following too:
{
Error: Unable to find bookmarks.html file.
Source File: resource://gre/components/nsSuiteGlue.js
Line: 653
}
which should be fixed by bug 628079 patch.

***

It also reports
{
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFService.GetDataSourceBlocking]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: chrome://communicator/content/sidebar/sidebarOverlay.js :: sidebar_overlay_init :: line 742"  data: no]
}
which might be caused by either of that bug or this one or maybe something else...
Depends on: 628079
(In reply to comment #8)
> It also reports
> {
> Error: uncaught exception: [Exception... "Component returned failure code:
> 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFService.GetDataSourceBlocking]" 
> nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame ::
> chrome://communicator/content/sidebar/sidebarOverlay.js :: sidebar_overlay_init
> :: line 742"  data: no]
> }
> which might be caused by either of that bug or this one or maybe something
> else...

This is this bug too:
manually extracting panels.rdf fixes the 2 js exceptions.
Untested, but that should be it per previous comments.
Assignee: nobody → sgautherie.bz
Status: NEW → ASSIGNED
Attachment #506465 - Flags: review?(kairo)
Component: Testing Infrastructure → Build Config
QA Contact: testing-infrastructure → build-config
Comment on attachment 506465 [details] [diff] [review]
(Av1) Keep panels.rdf out of omni.jar (ftb)

I don't know if I should do + or - here, actually. The general approach is just what I want, but this line isn't. Please restructure this in the same way as README_FILES is done, with line continuations by \ and a $(NULL) line at the end.
Attachment #506465 - Flags: review?(kairo) → review-
Av1, with comment 11 suggestion(s).
Attachment #506465 - Attachment is obsolete: true
Attachment #506549 - Flags: review?(kairo)
Comment on attachment 506549 [details] [diff] [review]
(Av2) Keep panels.rdf out of omni.jar (ftb)

Thanks, this one I like! :)
Attachment #506549 - Flags: review?(kairo) → review+
Av2, with removed-files.in change that I had missed.
Attachment #506549 - Attachment is obsolete: true
Attachment #506627 - Flags: review?(kairo)
Comment on attachment 506627 [details] [diff] [review]
(Av2a) Keep panels.rdf out of omni.jar (ftb)
[Checked in: Comment 16]

yanking review from KaiRo, this is good [the substantive thing is r+=KaiRo still, and the added part here is so trivial, keep r=him please]
Attachment #506627 - Flags: review?(kairo) → review+
Comment on attachment 506627 [details] [diff] [review]
(Av2a) Keep panels.rdf out of omni.jar (ftb)
[Checked in: Comment 16]

http://hg.mozilla.org/comm-central/rev/d1ae3f6b6b69
Attachment #506627 - Attachment description: (Av2a) Keep panels.rdf out of omni.jar (ftb) → (Av2a) Keep panels.rdf out of omni.jar (ftb) [Checked in: Comment 16]
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > Otherwise someone needs to find out how Firefox deals with the files in their
> > > omnijar!/defaults/profile/
> > As I recall they have code (possibly #ifdef MOZ_OMNIJAR) that looks for the
> > file in omni.jar if it can't find it in its previous location.
> 
> Well, not for panels.rdf, as they don't have something like that. Even
> SeaMonkey should get rid of this legacy one time, but for 2.1, I think it's too
> late in the game for something like that. Let's just add it to
> NON_OMNIJAR_FILES, that should fix this problem.

Please file a follow-up bug as need be.
Status: ASSIGNED → RESOLVED
blocking-seamonkey2.1: ? → ---
Closed: 9 years ago
Resolution: --- → FIXED
Summary: [SeaMonkey] mochitests-4: permanent "TEST-UNEXPECTED-FAIL | /tests/js/src/xpconnect/tests/mochitest/test_bug384632.html" due to assertion and js_error in (nsSidebar.js) RDF → mochitests-4: permanent "TEST-UNEXPECTED-FAIL | /tests/js/src/xpconnect/tests/mochitest/test_bug384632.html" due to assertion and js_error in (nsSidebar.js) RDF
Ftr, another test reported the same issue:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1295920771.1295922374.19785.gz&fulltext=1
WINNT 5.2 comm-central-trunk debug test crashtest on 2011/01/24 17:59:31
{
###!!! ASSERTION: null ptr: 'aURI != nsnull', file e:/builds/slave/comm-cen-trunk-w32-dbg/build/mozilla/rdf/base/src/nsRDFService.cpp, line 1416
...
JavaScript error: , line 0: uncaught exception: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFService.GetDataSource]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: resource://gre/components/nsSidebar.js :: nsSidebar :: line 86"  data: no]
...
REFTEST TEST-UNEXPECTED-FAIL | file:///e:/builds/slave/test/build/reftest/tests/dom/base/crashtests/244933-1.html | assertion count 1 is more than expected 0 assertions
}
Summary: mochitests-4: permanent "TEST-UNEXPECTED-FAIL | /tests/js/src/xpconnect/tests/mochitest/test_bug384632.html" due to assertion and js_error in (nsSidebar.js) RDF → mochitests-4: permanent "TEST-UNEXPECTED-FAIL | /tests/js/src/xpconnect/tests/mochitest/test_bug384632.html" due to assertion and js_error in (nsSidebar.js) RDF. (crashtest: 244933-1.html too)
The Makefile.in change (at least) was ignored by all builders :-(

I requested 1 clobber to check whether it makes any difference (as it should!):
"Linux x86-64 comm-central-trunk build / cb-seamonkey-linux64-01 / 2011-01-25 09:20:00 PST by"
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #19)

The removed-files.in change was taken into account, so a clobber should fix this situation :-)

Yet I wonder whether our build system is missing a dependency or something, as a clobber shouldn't be needed for a Makefile.in change, should it?
normally a clobber should not be needed, but I have seen weirdness with Makefile.in changes not triggering a Makefile regeneration sometimes myself, not sure why that is.
(In reply to comment #19)
> I requested 1 clobber to check whether it makes any difference (as it should!):
> "Linux x86-64 comm-central-trunk build / cb-seamonkey-linux64-01 / 2011-01-25
> 09:20:00 PST by"

That didn't help :-<

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1295979461.1295989590.19758.gz&fulltext=1
Linux x86-64 comm-central-trunk build on 2011/01/25 10:17:41
s: cb-seamonkey-linux64-01
{
comm-cen-trunk-lnx64:Server is forcing a clobber
comm-cen-trunk-lnx64:Clobbering...
Skipping tools
Removing build/
Removing codesize-auto-old.log
Skipping last-clobber
program finished with exit code 0
...
[...] zip -r9mX omni.jar [...] -x defaults/messenger/mailViews.dat chrome/icons/\* [...]
}

***

(In reply to comment #5)
> > +++ b/suite/locales/Makefile.in
> > +NON_OMNIJAR_FILES = defaults/messenger/mailViews.dat

Well, that really went unnoticed but
it's not 1 or 2 files that needed patching, but a 3rd one too:
http://mxr.mozilla.org/comm-central/search?string=NON_OMNIJAR_FILES&case=on
{
/suite/locales/Makefile.in
    * line 90 -- NON_OMNIJAR_FILES = \
/suite/installer/Makefile.in
    * line 147 -- NON_OMNIJAR_FILES = defaults/messenger/mailViews.dat
}

http://hg.mozilla.org/comm-central/rev/482e3d667fe6
(Bv1) Keep panels.rdf out of omni.jar (ftb), in /installer/Makefile.in too
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
(In reply to comment #22)
> http://hg.mozilla.org/comm-central/rev/482e3d667fe6
> (Bv1) Keep panels.rdf out of omni.jar (ftb), in /installer/Makefile.in too

Sure, silly me, should have noticed. the locales/ one is for L10n repacks only, and the en-US build needs it in installer/ of course.
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1296006039.1296009601.31132.gz
OS X 10.6 comm-central-trunk debug test mochitests-4/5 on 2011/01/25 17:40:39
{
mochitest-plain-4: 97009/0/139
}

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1296005653.1296005993.11204.gz
OS X 10.6 comm-central-trunk debug test crashtest on 2011/01/25 17:34:13
{
crashtest: 1793/0/52
}

V.Fixed
Status: RESOLVED → VERIFIED
(In reply to comment #23)
> (In reply to comment #22)
> > http://hg.mozilla.org/comm-central/rev/482e3d667fe6
> > (Bv1) Keep panels.rdf out of omni.jar (ftb), in /installer/Makefile.in too
> 
> Sure, silly me, should have noticed. the locales/ one is for L10n repacks only,
> and the en-US build needs it in installer/ of course.

I should have caught that too, it only needing patching in locales/ felt odd, but I didn't double check since KaiRo r+ed it. But O well, thanks serge!
Depends on: 629967
Blocks: 630124
You need to log in before you can comment on or make changes to this bug.