Closed Bug 1285475 Opened 9 years ago Closed 8 years ago

Intermittent sessionstore/test/browser_sessionStoreContainer.js | This test exceeded the timeout threshold. It should be rewritten or split up. If that's not possible, use requestLongerTimeout(N), but only as a last resort. -

Categories

(Firefox :: General, defect, P3)

Product:
Firefox
Component:
General
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE
Tracking Flags:
Tracking Status
firefox49 --- wontfix
firefox50 --- affected
firefox51 --- affected
firefox52 --- affected

People

(Reporter: intermittent-bug-filer, Unassigned)

Details

(Keywords: bulk-close-intermittents, intermittent-failure)

Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
Mike, could you help find someone to take a look at this issue? Another frequent session restore bug, looks like it spiked Nov 5th and much more Nov 18th: https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1285475&startday=2016-09-01&endday=2016-11-20&tree=all this falls into the pattern of a test timeout, maybe similar to bug 1252376 ?
Flags: needinfo?(mdeboer)
Well, yes, quite similar indeed, but I'm a bit wary about this... I can up the timeout on each and every sessionstore test, but I'd also like to point out that this something that started occurring more frequently not too long ago. Sessionstore mochitests are inherently heavy traffic on the platform side of things, by which I mean DOM/ XPCOM: a very large number of windows, tabs, browser elements instantiating multiple docShells and hard disk I/O when the sessionstore files are flushed to disk. Josh mentioned seeing a large number of ++/-- GC messages when studying the logs of intermittent bug 1252376: Did things change recently on the platform side of things that may affect the timing of the GC cycles? Is there a project running at the moment that intends to optimize memory usage, tweaked the GC behavior somewhat (or papercut by papercut) and might result in an increase of intermittents here? Who would know?
Flags: needinfo?(mdeboer)
Brad, would you know of any work in the last 3 weeks which could be fiddling with GC cycles or other major stuff landing on trunk. See comment 36 for more context.
Flags: needinfo?(blassey.bugs)
Bill, would any of your recent changes have changed timings here?
Flags: needinfo?(blassey.bugs) → needinfo?(wmccloskey)
Bug 1308039 landed on Oct 11, so it doesn't seem related to this bug. I don't know of anything else in this range. Mike, perhaps you could enable logging (via requestCompleteLog) for some of these tests that are failing. That would help see how long each step is taking. Also, the ++ messages have nothing to do with GC. The -- messages are sometimes correlated with GC activity, but not necessarily.
Flags: needinfo?(wmccloskey)
Status: NEW → RESOLVED
Closed: 8 years ago
Keywords: bulk-close-intermittents
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.