test_imapAuthMethods.js fails on Mac

NEW
Unassigned

Status

MailNews Core
Networking: IMAP
8 years ago
4 years ago

People

(Reporter: BenB, Unassigned)

Tracking

Trunk
x86
Mac OS X

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
Fallout from bug 525238:

TEST-UNEXPECTED-FAIL | /builds/slave/macosx-comm-central-check/build/objdir/mozilla/_tests/xpcshell/test_imap/unit/test_imapAuthMethods.js | 2147500036 - 
NEXT ERROR TEST-UNEXPECTED-FAIL | /builds/slave/macosx-comm-central-check/build/objdir/mozilla/_tests/xpcshell/test_imap/unit/head_server.js | capability, authenticate LOGIN, lsub, lsub == capability, authenticate LOGIN, lsub
(real, expected)

MacOSX 10.5 comm-central check on 2010/03/19 18:49:12
http://tinderbox.mozilla.org/showlog.cgi?log=Thunderbird/1269049752.1269052246.28271.gz#err2

So, I get one "lsub" more than expected.
I do:
    server.performTest("LSUB");
so it *should* stop after the first lsub. It works for me on Linux and, if the tinderboxen so far are any measure, on Windows as well, but that Mac OS X tinderbox failed in this way.

Investigate why or hack around it.
(Reporter)

Updated

8 years ago
Summary: test_imapAuthMethods.js fails on Mac or intermittently → test_imapAuthMethods.js fails on Mac
(Reporter)

Comment 1

8 years ago
(Probably threading issue on Mac?)
(Reporter)

Comment 2

8 years ago
Suggestions appreciated - I don't know the cause.
The comments in the test suggest that it's kinda expected to get a lot of extra LSUB's... so by threading problem, do you mean that on the mac the IMAP code manages to get in an extra LSUB before the unit test manages to kill it?
I've not got time to poke around at this today (otherwise I'd take a look for you). If you can't fix it in the short term, can you at least disable the test on Mac for the time being so that we haven't got permanent orange?

We normally do something like http://mxr.mozilla.org/comm-central/source/mailnews/local/test/unit/test_fileName.js#13 in these cases, this bug can then handle fixing it.
Hm, it definitely looks like the unit test is playing a dangerous race and it's probably losing on OS X.

This failure:
http://tinderbox.mozilla.org/showlog.cgi?tree=Thunderbird&errorparser=unittest&logfile=1269063445.1269065485.18769.gz&buildtime=1269063445&buildname=MacOSX%2010.5%20comm-central%20check&fulltext=1#err0

is because of this mismatch:
  capability, login, lsub, list == capability, login, lsub


On my linux box, I see the test pass, but sorta by the skin of its teeth... immediately after that check passes, I see:
  RECV: 5 list "" "INBOX"
  Received command 5
  SEND: * LIST () "/" "INBOX"
  SEND: 5 OK LIST completed
  SEND: 
  Connection Lost 2152398850
er, and because nsMailReader.prototype.onInputStreamReady spins on this._lines until it is empty regardless of when the driver wants to stop, that's likely why this happens.
I've pushed a modification to disable the test entirely since I'm a bit concerned about it also potentially being intermittently orange on other platforms:
http://hg.mozilla.org/comm-central/rev/ad45b1a6eae4

It seems like this is one of those pointy jabby testing framework edges that needs to be sanded down...
(Reporter)

Comment 8

8 years ago
Yes, I had massive pain (with the test framework) when writing this test and the POP variants, for exactly these reasons (event loops, threading etc.), with this one surely being the worst. The framework is all hacked together - the do_timeout(1000) in the IMAP tests are symptoms of that. Eventually, the fakeserver should run in its own thread.

I'll try to look into it how to fix this.
(Reporter)

Updated

8 years ago
Blocks: 525238
(Reporter)

Comment 9

8 years ago
I don't really know how to fix this...
First, I can't reproduce it here on Linux (neither opt nor debug).
Second, this is something freaky in the test framework in combination with IMAP being threaded.
The following line is problematic:
    server.performTest("LSUB");
If I use just server.performTest();, the test hangs at this point: I see the whole IMAP protocol chat, but performTest() never returns.
This really is a bug in the test framework (or at the very least totally lacking documentation). I don't even know what I am *supposed* to do, and there's nothing that would tell me.
(Reporter)

Comment 10

8 years ago
Docs say I should use just server.performTest(), but that obviously doesn't work.

FWIW, maild.js :
  performTest : function (watchWord) {
    this._watchWord = watchWord;
    var thread = gThreadManager.currentThread;
    while (!this.isTestFinished())
      thread.processNextEvent(false);
  },
imapd.js, run after each server command handling:
    if (this._lastCommand == reader.watchWord)
      reader.stopTest();
... which indirectly makes isTestFinished() go true and exit the above cited loop. That's why performTest("LSUB") returns, but performTest() does not.

So, the bug is that server.performTest() (without args) doesn't return, and I see nothing in my test that would cause it, so -> test framework.
Assignee: ben.bucksch → bugzilla
(Reporter)

Comment 11

8 years ago
Created attachment 436806 [details] [diff] [review]
Expose bug: Re-enable test and change to server.performTest()
Assignee: mbanner → nobody
You need to log in before you can comment on or make changes to this bug.