627417 - 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)

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Serge Gautherie (:sgautherie)]

(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
}

Comment 1

[Serge Gautherie (:sgautherie)]

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

Comment 2

[Serge Gautherie (:sgautherie)]

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?

Comment 3

[Philip Chee]

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?

Comment 4

[Philip Chee]

Blake, the test case from Bug 384632 has been failing since we switched to omnijar. Do you have any idea what's going wrong?

Comment 5

[Philip Chee]

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/

Comment 6

[[e-mail]]

(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.

Comment 7

[Robert Kaiser]

(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.

Comment 8

[Serge Gautherie (:sgautherie)]

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...

Comment 9

[Serge Gautherie (:sgautherie)]

(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.

Comment 10

[Serge Gautherie (:sgautherie)]

Attachment: (Av1) Keep panels.rdf out of omni.jar (ftb)

Untested, but that should be it per previous comments.

Comment 11

[Robert Kaiser]

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.

Comment 12

[Serge Gautherie (:sgautherie)]

Attachment: (Av2) Keep panels.rdf out of omni.jar (ftb)

Av1, with comment 11 suggestion(s).

Comment 13

[Robert Kaiser]

Comment on attachment 506549 [details] [diff] [review]
(Av2) Keep panels.rdf out of omni.jar (ftb)

Thanks, this one I like! :)

Comment 14

[Serge Gautherie (:sgautherie)]

Attachment: (Av2a) Keep panels.rdf out of omni.jar (ftb) [Checked in: Comment 16]

Av2, with removed-files.in change that I had missed.

Comment 15

[Justin Wood (:Callek)]

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]

Comment 16

[Serge Gautherie (:sgautherie)]

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

Comment 17

[Serge Gautherie (:sgautherie)]

(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.

Comment 18

[Serge Gautherie (:sgautherie)]

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
}

Comment 19

[Serge Gautherie (:sgautherie)]

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"

Comment 20

[Serge Gautherie (:sgautherie)]

(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?

Comment 21

[Robert Kaiser]

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.

Comment 22

[Serge Gautherie (:sgautherie)]

(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

Comment 23

[Robert Kaiser]

(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.

Comment 24

[Serge Gautherie (:sgautherie)]

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

Comment 25

[Justin Wood (:Callek)]

(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!