Open Bug 553764 Opened 10 years ago Updated 5 months ago

test_imapAuthMethods.js fails on Mac


(MailNews Core :: Networking: IMAP, defect)

Not set


(Not tracked)


(Reporter: BenB, Unassigned)




(1 file)

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

So, I get one "lsub" more than expected.
I do:
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.
Summary: test_imapAuthMethods.js fails on Mac or intermittently → test_imapAuthMethods.js fails on Mac
(Probably threading issue on Mac?)
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 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:

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

It seems like this is one of those pointy jabby testing framework edges that needs to be sanded down...
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.
Blocks: 525238
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:
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.
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())
imapd.js, run after each server command handling:
    if (this._lastCommand == reader.watchWord)
... 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
Assignee: mbanner → nobody

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

You need to log in before you can comment on or make changes to this bug.