Closed Bug 697943 Opened 8 years ago Closed 8 years ago

Random orange: TEST-UNEXPECTED-FAIL | test_offlineStoreLocking.js | 128 == false

Categories

(MailNews Core :: Networking: IMAP, defect)

defect
Not set

Tracking

(thunderbird10 fixed, thunderbird11 fixed)

RESOLVED FIXED
Thunderbird 12.0
Tracking Status
thunderbird10 --- fixed
thunderbird11 --- fixed

People

(Reporter: standard8, Assigned: Bienvenu)

References

()

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

This orange has been popping up a bit over the last few weeks. Log:

TEST-UNEXPECTED-FAIL | /buildbot/comm-central-linux-opt-unittest-xpcshell/build/xpcshell/tests/mailnews/imap/test/unit/test_offlineStoreLocking.js | test failed (with xpcshell return code: 0), see following log:
>>>>>>>

TEST-INFO | (xpcshell/head.js) | test 1 pending
Directory request for: MailD that we (mailDirService.js) are not handling, leaving it to another handler.
Directory request for: MFCaF that we (mailDirService.js) are not handling, leaving it to another handler.
Directory request for: DefRt that we (mailDirService.js) are not handling, leaving it to another handler.
Directory request for: IMapMD that we (mailDirService.js) are not handling, leaving it to another handler.

TEST-INFO | (xpcshell/head.js) | test 2 pending
Doing test 1
Downloading for offline use

TEST-INFO | (xpcshell/head.js) | test 2 finished

TEST-INFO | (xpcshell/head.js) | running event loop
AUTH PLAIN line -AHVzZXIAcGFzc3dvcmQ=-
authorize-id: --, username: -user-, password: -password-

TEST-PASS | /buildbot/comm-central-linux-opt-unittest-xpcshell/build/xpcshell/tests/mailnews/imap/test/unit/test_offlineStoreLocking.js | [null : 366] 0 == 0
Doing test 2

TEST-PASS | /buildbot/comm-central-linux-opt-unittest-xpcshell/build/xpcshell/tests/mailnews/imap/test/unit/test_offlineStoreLocking.js | [null : 351] 0 == 0
Doing test 3
Directory request for: cachePDir that we (mailDirService.js) are not handling, leaving it to another handler.
Directory request for: cachePDir that we (mailDirService.js) are not handling, leaving it to another handler.

TEST-PASS | /buildbot/comm-central-linux-opt-unittest-xpcshell/build/xpcshell/tests/mailnews/imap/test/unit/test_offlineStoreLocking.js | [null : 366] 0 == 0
Doing test 4

TEST-UNEXPECTED-FAIL | /buildbot/comm-central-linux-opt-unittest-xpcshell/build/xpcshell/tests/mailnews/imap/test/unit/test_offlineStoreLocking.js | 128 == false - See following stack:
JS frame :: /buildbot/comm-central-linux-opt-unittest-xpcshell/build/xpcshell/head.js :: do_throw :: line 453
JS frame :: /buildbot/comm-central-linux-opt-unittest-xpcshell/build/xpcshell/head.js :: _do_check_eq :: line 547
JS frame :: /buildbot/comm-central-linux-opt-unittest-xpcshell/build/xpcshell/head.js :: do_check_eq :: line 568
JS frame :: /buildbot/comm-central-linux-opt-unittest-xpcshell/build/xpcshell/head.js :: do_check_false :: line 596
JS frame :: /buildbot/comm-central-linux-opt-unittest-xpcshell/build/xpcshell/tests/mailnews/imap/test/unit/test_offlineStoreLocking.js :: <TOP_LEVEL> :: line 105

TEST-INFO | (xpcshell/head.js) | exiting test
David, can you take a look at this, it seems to have suddenly got a lot more frequent?
Line 105 is:
{
102   onStopRequest : function (aRequest, aContext, aStatusCode) {
103     // Because we're streaming the message while compaction is going on,
104     // we should not have stored it for offline use.
105     do_check_false(gStreamedHdr.flags & Ci.nsMsgMessageFlags.Offline);
106     do_timeout(0, function(){doTest(++gCurTestNum)});
107   },
}
I haven't had any luck reproducing this, but I'll remove the windows disabling of this test and see if I can't reproduce it.
Assignee: nobody → dbienvenu
I can make this fail now that I can run windows release builds, if I enable the test on Windows. I'll investigate.
Status: NEW → ASSIGNED
It looks like the compact finishes before we attempt to do the stream. I'm not sure why this is different in release mode; it could be the event loop isn't getting a chance to run the imap url until the compact finishes.
OK, the way out of this might be to stream the message without a display consumer; that will make us run the url immediately, instead of using AsyncOpen, which involves a few trips through the event loop. I believe the test is still valid, because we don't write to the offline store via the display consumer. I'll attach a patch once I've rebuilt...
Attached patch proposed fixSplinter Review
This turns the test back on for windows, gets rid of an unused method, makes the messages have bigger bodies to make the compact take longer, and streams the message w/o a stream listener so that the url runs sooner. I'll kick off a try server build later today.
Attachment #590018 - Flags: review?(mbanner)
Comment on attachment 590018 [details] [diff] [review]
proposed fix

Try seems happy and the changes look good :-)
Attachment #590018 - Flags: review?(mbanner) → review+
http://hg.mozilla.org/comm-central/rev/b6160b9a2dc4
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 12.0
So far I've not spotted the linux issue recurring, however the Windows issue is still there (permanently), therefore I've re-disabled the test on Windows:

http://hg.mozilla.org/comm-central/rev/205b8ff54fe0

We should probably cover enabling it again in a different bug.
Attachment #590018 - Flags: approval-comm-beta+
Attachment #590018 - Flags: approval-comm-aurora+
No longer depends on: OrangeFactorCommApps
http://tinderbox.mozilla.org/showlog.cgi?log=ThunderbirdTrunk/1330354454.1330355619.32145.gz
MacOSX 10.6 comm-central test xpcshell on 2012/02/27 06:54:14

Still happening...
Whiteboard: [tb-orange]
You need to log in before you can comment on or make changes to this bug.