gather_debug() fails with [Errno 10054] An existing connection was forcibly closed by the remote host



4 years ago
4 years ago


(Reporter: whimboo, Unassigned)


41 Branch
Dependency tree / graph

Firefox Tracking Flags

(firefox41 affected)



(1 attachment)

Posted file log.txt
With our Firefox UI tests we see a lot of the following type of failure especially in our update tests.

[Errno 10054] An existing connection was forcibly closed by the remote host

Traceback (most recent call last):

  File "c:\jenkins\workspace\mozilla-central_update\venv\lib\site-packages\marionette\runner\", line 561, in gather_debug
    with marionette.using_context(marionette.CONTEXT_CHROME):

  File "C:\Python27\Lib\", line 17, in __enter__

  File "c:\jenkins\workspace\mozilla-central_update\venv\lib\site-packages\marionette_driver\", line 1159, in using_context
    scope = self._send_message('getContext', 'value')

  File "c:\jenkins\workspace\mozilla-central_update\venv\lib\site-packages\marionette_driver\", line 36, in _
    return func(*args, **kwargs)

  File "c:\jenkins\workspace\mozilla-central_update\venv\lib\site-packages\marionette_driver\", line 687, in _send_message
    response = self.client.send(message)

  File "c:\jenkins\workspace\mozilla-central_update\venv\lib\site-packages\marionette_transport\", line 101, in send
    raise e

Affected line of code:

I don't see a pattern yet when it happens. It seems to be random. Maybe I'm able to get a reduced testcase for it and have it reproducible all the time.
Blocks: m21s
Severity: normal → major
I ran this test a dozen of times but the given problem did not re-appear. So not exactly sure what triggers this disconnect. My feeling is that it happens due to one of the requested restarts of Firefox, and that in such a case the Marionette client is still trying to send a message while the server in Firefox already closed the connection. 

I will keep the machine mm-win-8-64-4 offline and do a long-time test on it. Maybe it will reproduce in at least one of thousand runs.
More testing has shown that this seems to only be an issue with the mm-win-8-64-4 VM in SCL3. All other VMs seem to work regarding this reported problem. But given that other machines of this Windows version seem to have focus issues, I requested a re-deployment of all VMs from the template. It should fix this particular issue, which I was not able to reproduce at all.

I will mark the bug as incomplete for now and will reopen if I'm able to reproduce once it happens again.
Last Resolved: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.