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

RESOLVED FIXED in Thunderbird 12.0


MailNews Core
Networking: IMAP
6 years ago
5 years ago


(Reporter: standard8, Assigned: Bienvenu)



Thunderbird 12.0

Thunderbird Tracking Flags

(thunderbird10 fixed, thunderbird11 fixed)




(1 attachment)

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

Comment 3

6 years ago
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
Depends on: 712540

Comment 4

6 years ago
I can make this fail now that I can run windows release builds, if I enable the test on Windows. I'll investigate.

Comment 5

6 years ago
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.

Comment 6

6 years ago
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...

Comment 7

6 years ago
Created attachment 590018 [details] [diff] [review]
proposed fix

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 8

6 years ago
Comment on attachment 590018 [details] [diff] [review]
proposed fix

Try seems happy and the changes look good :-)
Attachment #590018 - Flags: review?(mbanner) → review+

Comment 10

6 years ago
Last Resolved: 6 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:


We should probably cover enabling it again in a different bug.
I've checked the test fix and the bustage fix into the branches as this should reduce failures there as well:

status-thunderbird10: --- → fixed
status-thunderbird11: --- → fixed
Attachment #590018 - Flags: approval-comm-beta+
Attachment #590018 - Flags: approval-comm-aurora+
No longer depends on: 712540
MacOSX 10.6 comm-central test xpcshell on 2012/02/27 06:54:14

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