Closed Bug 485678 Opened 15 years ago Closed 15 years ago

test_browserGlue_corrupt_nobackup_default.js fails on Mac (1.9.1 branch)

Categories

(Toolkit :: Places, defect)

Product:
Toolkit
Component:
Places
Version:
1.9.1 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: ehsan.akhgari, Assigned: mak)

References

(
URL
)

Details

(Keywords: fixed1.9.1, intermittent-failure, regression, Whiteboard: [fixed by bug 486008]) 

uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIFile.remove]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: /builds/slave/mozilla-1.9.1-macosx-unittest/build/objdir/_tests/xpcshell/test_browser_places/unit/head_bookmarks.js :: <TOP_LEVEL> :: line 67"  data: no]

this is head file trying to remove the profile folder

[Exception... "Component returned failure code: 0x80520014 (NS_ERROR_FILE_DIR_NOT_EMPTY) [nsIFile.remove]"  nsresult: "0x80520014 (NS_ERROR_FILE_DIR_NOT_EMPTY)"  location: "JS frame :: /builds/slave/mozilla-1.9.1-macosx-unittest/build/objdir/_tests/xpcshell/test_browser_places/unit/head_bookmarks.js :: remove_bookmarks_html :: line 205"  data: no]

this is the call to gProfD.clone() (even if appear more as the removal of the .html file, but it's not a dir)

uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: /builds/slave/mozilla-1.9.1-macosx-unittest/build/objdir/_tests/xpcshell/test_browser_places/unit/tail_bookmarks.js :: <TOP_LEVEL> :: line 57"  data: no]

and here is impossible to get history service...

No idea what could have been changed that did not change on m-c, sounds more like a box issue, but can't be sure, nor can i try to reproduce this OS X only failure
ted rewrite of xpcshell landed not much time before, so could be related, even if at that point i would expect to see the same problem on m-c
Happened again: <http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1238227977.1238230688.5320.gz>.  Maybe we should back out bug 424377?  I'm hesitant to do so myself because I can't even comment on that bug or reopen it.
Doesn't sound as a good idea since nobody of us can access that bug, the push itself does not sound related to me (but i don't know that code).

Supposing that a file in the profile folder is in use, and the removal of the profile folder fails (which file? and why it was not failing before?), what i really don't understand is the second NS_ERROR_FILE_DIR_NOT_EMPTY error, near that line we try to remove a file, not a directory, and that's not on line 205, where we simply clone() the previously failed removed dir.
bug 424377 is just about printing, so I'd be very surprised if it caused this.
Smaug backed out bug 424377.  It would be great if someone can watch the tree to see if that box turns green, because he won't be around and neither would I (most likely).
as expected backout was un-effective, problem still there.
Blocks: 438871
Whiteboard: [orange]
Running the unit test test_browserGlue_corrupt_nobackup.js in
browser/components/places/tests/unit causes the next test,
test_browserGlue_corrupt_nobackup_default.js, to fail on Mac OS X
10.4/10.5.  This appears due to the set of changes Ted made to the
xpcshell test harness:

  http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?startdate=2009-03-27&enddate=2009-03-28

At 3/27 5:11am PST he reverted previous checkin's (changeset
e536dd81d066), then checked in a bunch of changes at 6:23am, the last in
changeset 3bd4730954eb.  Running just the tests in
browser/components/places, the tests pass with changeset cd99dc2701b0,
prior to these checkins, and fails with changeset 3bd4730954eb.

To run just the tests that are failing, use:

  cd objdir
  make -C browser/components/places/tests check

Not sure if the resulting bug is one in Marco's tests that was simply
flushed out by updating the test harness or if the bug is actually in
the underlying places code.  Until that's resolved I'm disabling this
test:

  http://hg.mozilla.org/releases/mozilla-1.9.1/rev/e95b26982e96

If you see a failure like this, please disable the test or pull out the
set of changesets that cause the test to fail.  Leaving a test like this
that causes periodic orange is deadly to everyone's productivity.

Ted, did this test work for you on Mac OS X when you tested before
checking in your changes?
Isn't the do_test_finished() on line 86

84   let bs = Cc["@mozilla.org/browser/nav-bookmarks-service;1"].
85            getService(Ci.nsINavBookmarksService);
86 do_test_finished();
87   if (bs.getIdForItemAt(bs.toolbarFolder, 0) == -1) {

very much surplus to requirements
dunno if related but that's an error though, i probably left that in while debugging, i'll file a bug on that to fix the test, apart from this.
Btw i have to point out that the same exact tests are running fine on m-c, i would expect an error in the test be catched on both trunk and branch, also i don't see why this would be an issue on OS X only. i suspect is somehow related to the leaks in bug 485648 (OS X only)
John: I didn't run the full unit test suite on 1.9.1 prior to pushing that change. I ran it on Linux and everything worked fine. The same code is on trunk and working fine, and I ran the tests on all three platforms before pushing it there.
Depends on: 486008
filed Bug 486008 for the wrong test code, after fixing that i'll try to renable the new version on 1.9.1, i suspect we could run into a condition where places.sqlite is wrongly locked. i can't be sure though till i try that.
The error looks like a file-not-found error, not a leak problem:

2009-03-31 09:24:00.773 xpcshell[30589:10b] DebugAssert: Third Party Client: result == 0  [-47 = fBsyErr] FSDeleteContainerContents [/builds/moz191/xpcom/MoreFiles/MoreFilesX.c:1580]
uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIFile.remove]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: /builds/moz191/obj-debug/_tests/xpcshell/test_browser_places/unit/head_bookmarks.js :: <TOP_LEVEL> :: line 67"  data: no]
*** test pending
[Exception... "Component returned failure code: 0x80520014 (NS_ERROR_FILE_DIR_NOT_EMPTY) [nsIFile.remove]"  nsresult: "0x80520014 (NS_ERROR_FILE_DIR_NOT_EMPTY)"  location: "JS frame :: /builds/moz191/obj-debug/_tests/xpcshell/test_browser_places/unit/head_bookmarks.js :: remove_bookmarks_html :: line 205"  data: no]
*** FAIL ***

Marco, don't you need to pass in a filename to create_bookmarks_html() in 
test_browserGlue_corrupt_nobackup.js?

test_browserGlue_corrupt_nobackup.js:50:    create_bookmarks_html();
test_browserGlue_corrupt.js:47:    create_bookmarks_html("bookmarks.glue.html");
test_browserGlue_migrate.js:52:    create_bookmarks_html("bookmarks.glue.html");
test_browserGlue_prefs.js:240:    create_bookmarks_html("bookmarks.glue.html");
test_browserGlue_restore.js:47:    create_bookmarks_html("bookmarks.glue.html");
test_browserGlue_shutdown.js:100:      let profileBookmarksHTMLFile = create_bookmarks_html("bookmarks.glue.html");

Adding the filename fixes the error, not sure if that's right for your what you're testing or not.  Trunk has the same test code but trunk contains changes to the Mac file code that's not on 1.9.1, that must be why this error doesn't show up on trunk.

Aren't branches fun? ;)
yeah i'm following that code in my new Bug 486008, i suspect your theory could be the correct one (that's a real error), and if that's the case i can't see why trunk is happy with that.
(In reply to comment #15)
> Trunk has the same test code but trunk contains changes
> to the Mac file code that's not on 1.9.1, that must be why this error doesn't
> show up on trunk.

i would believe in this, but the test was living on branch before this failures. So that could be right, and probably that with ted's changes have made this visible. actual patch in Bug 486008 should solve this too.
@Marco
Great, let me know if you need to test a patch on Mac OS X.

(In reply to comment #13)
> John: I didn't run the full unit test suite on 1.9.1 prior to pushing that
> change. I ran it on Linux and everything worked fine. The same code is on trunk
> and working fine, and I ran the tests on all three platforms before pushing it
> there.

Makes sense, but I think the 1.9.1 branch contains enough differences (e.g. Mac OS X file code in this case) that big changes like rewriting the xpcshell harness (http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f51e8453c310) probably need to be run on all platforms before checkin.  A complete pain, I realize...
Yeah, sorry, I didn't realize there was enough code drift to cause a problem like this.
i re-enabled the fixed version of the test, and i'm waiting for results.
got a green on all three reference platforms, i suppose we can consider this fixed by bug 486008.
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: fixed1.9.1
Resolution: --- → FIXED
Whiteboard: [orange] → [orange][fixed by bug 486008]
Assignee: nobody → mak77
Whiteboard: [orange][fixed by bug 486008] → [fixed by bug 486008]
You need to log in before you can comment on or make changes to this bug.