Intermittent test_switch_remote_frame.py TestSwitchRemoteFrame.test_we_can_switch_to_a_remote_frame_by_index | TimeoutException: TimeoutException: Connection timed out| application crashed

RESOLVED WORKSFORME

Status

defect
RESOLVED WORKSFORME
5 years ago
3 years ago

People

(Reporter: cbook, Unassigned)

Tracking

({intermittent-failure, pi-marionette-intermittent})

Firefox Tracking Flags

(firefox36 unaffected, firefox37 wontfix, firefox38 wontfix, firefox39 wontfix, firefox40 wontfix, firefox41 disabled, firefox-esr31 unaffected, firefox-esr38 wontfix)

Details

()

Rev5 MacOSX Mountain Lion 10.8 mozilla-inbound debug test marionette

https://treeherder.mozilla.org/logviewer.html#?job_id=4903403&repo=mozilla-inbound

21:40:53 ERROR - TEST-UNEXPECTED-ERROR | test_switch_remote_frame.py TestSwitchRemoteFrame.test_we_can_switch_to_a_remote_frame_by_index | TimeoutException: TimeoutException: Connection timed out
Dave, do you have spare cycles to look into this frequent 10.8 Mn failure?
Component: JavaScript Engine → Marionette
Flags: needinfo?(dburns)
Product: Core → Testing
Looking at this, I wonder if the test has found a real issue since the browser is crashing in a11y code
Flags: needinfo?(dburns)
Is this something that you can help with. It looks like Marionette is causing a crash in a11y code intermittently.
Flags: needinfo?(surkov.alexander)
Is the test running in multiprocess Firefox? Out of curiosity do you know how a11y gets enabled here?
Flags: needinfo?(surkov.alexander)
No, we are not running this in e10s, that is in a separate job on treeherder.

The test[1] is creating a OOP frame and when we check what process is not the main one[2] then we appear to hit the crash that is mentioned in above. 


[1] https://dxr.mozilla.org/mozilla-central/source/testing/marionette/client/marionette/tests/unit/test_switch_remote_frame.py#91
[2] https://dxr.mozilla.org/mozilla-central/source/testing/marionette/client/marionette/tests/unit/test_switch_remote_frame.py#106
(In reply to David Burns :automatedtester from comment #101)
> No, we are not running this in e10s, that is in a separate job on treeherder.
> 
> The test[1] is creating a OOP frame and when we check what process is not
> the main one[2] then we appear to hit the crash that is mentioned in above. 

sorry for my ignorance but what's difference between e10s and dealing with OOP frames? Does it crash in main process?
I can't see anywhere were we are explicitly switching on a11y stuff. When would someone in your team be able to look at it because from the marionette side we are just running some JS to check if we are in the main process. We are recreating OOP frames like b2g which, as far as I understand it were the precursor to e10s and have their own special snowflake sandboxing. This is making sure frames can't speak by moving them OOP instead of making tabs OOP.

We check if we are in the main thread because we shouldnt but running this of the main thread is causing the crash, I think.
Flags: needinfo?(surkov.alexander)
Trevor, do you have ideas what may happen here?
Flags: needinfo?(surkov.alexander) → needinfo?(tbsaunde+mozbugs)
(In reply to alexander :surkov from comment #147)
> Trevor, do you have ideas what may happen here?

not off hand, why doesn't someone try and debug it?
Flags: needinfo?(tbsaunde+mozbugs)
(In reply to Trevor Saunders (:tbsaunde) from comment #174)
> (In reply to alexander :surkov from comment #147)
> > Trevor, do you have ideas what may happen here?
> 
> not off hand, why doesn't someone try and debug it?

Sure if no good ideas so far. Do you want to give it a try?