651474 - Random Orange TEST-UNEXPECTED-FAIL | test-display-issues.js | Exited with code 1 during test_buttons_collapse_and_expand in quick-filter-bar tests

Status: RESOLVED WORKSFORME

(Thunderbird :: General, defect)

Description

[Mark Banner (:standard8)]

We're seeing this quite frequently on the Linux tinderboxes:

mozmill.setState :: 'currentState'
mozmill.setTest :: {'name': 'test_buttons_collapse_and_expand', 'filename': '/buildbot/comm-central-linux64-opt-unittest-mozmill/build/mozmill/quick-filter-bar/test-display-issues.js'}
error: uncaptured python exception, closing channel <jsbridge.network.BackChannel connected 127.0.0.1:24242 at 0x2dc9758> (<type 'exceptions.KeyError'>:'message' [/tools/python/lib/python2.5/asyncore.py|readwrite|93] [/tools/python/lib/python2.5/asyncore.py|handle_read_event|390] [/tools/python/lib/python2.5/site-packages/jsbridge/network.py|handle_read|93] [/tools/python/lib/python2.5/site-packages/jsbridge/network.py|process_read|253] [/tools/python/lib/python2.5/site-packages/jsbridge/network.py|fire_callbacks|268] [/tools/python/lib/python2.5/site-packages/jsbridge/network.py|fire_event|289] [/tools/python/lib/python2.5/site-packages/mozmill/__init__.py|__call__|104] [runtest.py|logFailure|362])
endRunner was never called. There must have been a failure in the framework.
##### MOZMILL-RICH-FAILURES-BEGIN #####
##### MOZMILL-RICH-FAILURES-END #####
TEST-PASS | test_sticky_basics
TEST-PASS | test_sticky_tags
TEST-PASS | test_sticky_text
TEST-UNEXPECTED-FAIL | (runtestlist.py) | Exited with code 1 during directory run
INFO | (runtestlist.py) | quick-filter-bar: 3 passed, 0 failed

It looks like Thunderbird is exiting early, which would imply a crash, but we should have crash handling in place to detect the crash and log the actual crash point.

So I'm not quite sure what is going on here.

Comment 1

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

Per discussion on IRC, I think I may have (accidentally) developed changes to this test using a more recent version of mozmill which is better about catching/logging things.  I think we are converting a recoverable failure into an unlogged unrecoverable failure.  I will use the new orange-fix rubber-stamp for logging to try and resolve the death and then resolve the underlying orange.

Comment 2

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

This also looks like it may be a victim of the random test execution sequencing on linux.

Comment 3

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

Pushed a simple-orange-fix to trunk:
http://hg.mozilla.org/comm-central/rev/168b4af06ad6

The green try push was:
http://hg.mozilla.org/try-comm-central/rev/37ca9c8a7aca

The hypothetical fix is that immediately before performing our assertion check where we explode, we introduce an additional spinning wait to ensure the window size is actually what we want.  This is a linux-only thing because of the asynchronous window manager and some lying on the part of the platform.

It's not clear that this will fix the problem given the platform's ability to lie.  If this does not do it, the right thing to do is probably to change the spinning to one that assumes our logic works and that times-out in the case it does not.

I have not changed the type of the assertions at this time, so if I don't fix this, the mozmill death problem will likely keep happening.

Comment 4

[Mark Banner (:standard8)]

Assuming asuth isn't working on this. We're still seeing it reasonably frequently, not sure if its got worse recently.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

I have so far been unsuccessful in reproducing this locally on my OSX machine.

Comment 6

[Mark Banner (:standard8)]

Yeah I totally forgot this is a screen resolution problem as a result of the swap to new builders.

I think we can call this bug WFM for now.