Closed Bug 1114895 Opened 10 years ago Closed 9 years ago

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

Categories

(Testing :: Marionette Client and Harness, defect)

Product:
Testing
Component:
Marionette Client and Harness
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

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

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox36 --- unaffected
firefox37 --- wontfix
firefox38 --- wontfix
firefox39 --- wontfix
firefox40 --- wontfix
firefox41 --- disabled
firefox-esr31 --- unaffected
firefox-esr38 --- wontfix

People

(Reporter: cbook, Unassigned)

References

(
URL
)

Details

(Keywords: intermittent-failure, pi-marionette-intermittent) 

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?
status-firefox36: --- → unaffected
status-firefox37: --- → affected
status-firefox38: --- → affected
status-firefox-esr31: --- → unaffected
Component: JavaScript Engine → Marionette
Flags: needinfo?(dburns)
Keywords: ateam-marionette-intermittent
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?