15.81 KB, text/plain
15.32 KB, text/plain
148.61 KB, text/plain
2.76 KB, patch
|Details | Diff | Splinter Review|
Created attachment 462741 [details] Failing test After we landed bug 580108, test_localToImapFilterQuarantine.js is permanently failing on Linux. This is strange, because a test shouldn't be relying on a server timeout to pass, or certainly not without explicit confirmation. Also, it is only happening on Linux (both 32 and 64 bit). I've disabled the test on Linux for now, but we should try and fix the issue with the test. I'll attach a couple of log files (with just imap logging on), one before bug 580108, and one after.
Created attachment 462742 [details] "pass" log The "pass" case is definitely waiting for a timeout - I discovered that when generating the log.
can you tell where in the log it's waiting for the timeout? And which server is timing out (the pop3 one or the imap one?) The good news is that fixing this will speed up the linux tests by three minutes :-)
actually, adding timestamp to the imap log would be helpful, as well as turning on the pop3 logging...
Summary: test_localToImapFilterQuarantine.js fails on Linux after bug 580108 → test_localToImapFilterQuarantine.js intermittent timeout on Linux | test failed (with xpcshell return code: 0)
http://tinderbox.mozilla.org/showlog.cgi?log=Thunderbird/1284963793.1284968586.11746.gz&fulltext=1 Linux x86-64 comm-central check on 2010/09/19 23:23:13 Same log as in bug 596184 comment 0: It looks like http://hg.mozilla.org/comm-central/rev/f28c929a61a1 "Shorten the asyncTestUtils timeout to just under 300 seconds ..." made no difference.
(In reply to comment #4) > http://tinderbox.mozilla.org/showlog.cgi?log=Thunderbird/1284963793.1284968586.11746.gz&fulltext=1 > Linux x86-64 comm-central check on 2010/09/19 23:23:13 No need to comment every time thanks, I know this is a very frequent failure at the moment and its on my things of to look at. > Same log as in bug 596184 comment 0: (hence the dependency)
Created attachment 477060 [details] Log of failure with NSPR_LOG_MODULES=imap:5,pop3:5,smtp:5,MSGDB:5,timestamp Got this last night at the 29. run of the mailnews xpcshell-tests on Linux. So still there but quite rare.
Created attachment 477896 [details] [diff] [review] Possible fix [Checked in: Comment 7] I've just landed this to try and fix the issue (as the Thunderbird Linux tinderboxes were pretty much permanently orange due to this and other errors). The issue and solution goes something like this: 1) Mail is downloaded from the pop3 server. 2) That mail is filtered across to the imap server. 3) We then update the folder so that we can check its contents. However, there is no notification for the APPEND that the filtering is doing in step 2. So sometimes (as in the log attached to this bug), that APPEND fails. At this point, UpdateFolderWithListener returns silently and OnStopRunningURL never gets called. We then get stuck ;-) So I've changed the test to re-run UpdateFolderWithListener occasionally so that we can ensure we get the listener. The test worked fine locally for me with the changes - I'd previously been able to replicate it by putting my machine under a little bit of load. Given the tree is so bad wrt orange at the moment, I checked it in and hopefully this will green it up a bit: http://hg.mozilla.org/comm-central/rev/b07527a173c0
Assignee: nobody → bugzilla
Status: NEW → ASSIGNED
I've not seen this since I landed the patch, and it was pretty frequent on Linux before I did so. Therefore tentatively marking as fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Looking at the patch, would it be fair to say that the test has uncovered a core flaw (that UpdateFolderWithListener does not properly indicate when it is done)? If so, it seems odd to me to "fix" the test by working around the core flaw, rather than fixing the core flaw. The point of tests after all is to test, not to just run without failure (unlike an extension, where I do this kind of workaround all of the time). With our current testing platform, there is no real support for tests that have known issues that need fixing, so I guess a workaround is the only alternative. But me thinks you should at least spin off a core bug, pointing to this one, that requests that the core issue be fixed.
Status: RESOLVED → VERIFIED
Target Milestone: --- → Thunderbird 3.3a1
Thanks fro filing the bug - I was thinking about filing it at the time, but forgot.
Attachment #477896 - Attachment description: Possible fix → Possible fix [Checked in: Comment 7]
You need to log in before you can comment on or make changes to this bug.