1305368 - [e10-multi] Lot's of "This test exceeded the timeout threshold. It should be rewritten or split up." failures with multiple content process

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, defect)

Description

[Gabor Krizsanits (INACTIVE)]

Many of the test fails because timeouts on ash. I investigated this and similarly to the tab close timeouts opening new tabs (and loading some content in them) became significantly slower in browser chrome test (2,5x slower). So a bunch of tests that are already intermittently times out with this message turns perma orange, and some of the tests that already doing requestLongerTimeout should be bumped up to call it with a bigger number.

I'm not sure if it's an acceptable fix even for temporarily. But we have to talk this over during our next meeting. In the meanwhile I will try to do some more measurements.

I checked if this comes from the shim layer that comes with browser chrome tests, but no, waiving the shim layer does not help.

If we have multiple content process than opening a new tab starts a new process so that is expected to be slower, the weird thing however is the many WARNING: pipe error: Broken pipe: on the console.

If we force single content process for a test, before the test would start the browser chrome test suite opens and closes some windows/tabs during init (when the multi process is still enabled) which starts and kills a couple of content processes, which results in the same Broken pipe warnings and probably related to that slows down the test in the beginning.

Comment 1

[Gabor Krizsanits (INACTIVE)]

We'll have to make a decisions here about how we want to progress with this issue, I'm setting the needinfo flag just to make sure we won't forget to talk this over.

Comment 2

[Gabor Krizsanits (INACTIVE)]

So I've simulated the browser chrome test utils, and opened a tab, loaded an uri from a local http server and the closed the tab a few times. With the profiler attached this is the result (note that this is a debug build): https://cleopatra.io/#report=33e56390183eed972ef42a34c2a4ad6298bcaed7

It seems like the content process at startup spending long seconds in the SDK's loader (http://searchfox.org/mozilla-central/source/addon-sdk/source/lib/toolkit/loader.js#628)

I'll continue from here tomorrow.

Comment 3

[Gabor Krizsanits (INACTIVE)]

Bug 1308895 fixed this so I'm closing this for now.