553764 - test_imapAuthMethods.js fails on Mac

Status: NEW

(MailNews Core :: Networking: IMAP, defect)

Description

[Ben Bucksch (:BenB)]

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.

Comment 1

[Ben Bucksch (:BenB)]

(Probably threading issue on Mac?)

Comment 2

[Ben Bucksch (:BenB)]

Suggestions appreciated - I don't know the cause.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

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?

Comment 4

[Mark Banner (:standard8)]

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.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

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

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

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.

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

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...

Comment 8

[Ben Bucksch (:BenB)]

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.

Comment 9

[Ben Bucksch (:BenB)]

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.

Comment 10

[Ben Bucksch (:BenB)]

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.

Comment 11

[Ben Bucksch (:BenB)]

Attachment: Expose bug: Re-enable test and change to server.performTest()

Comment 12

[:aceman]

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #5)

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

This still happens even today and on Linux.