Closed Bug 1185674 Opened 9 years ago Closed 8 years ago

Session restore doesn't seem to work correctly (hangs) with e10s

Categories

(Core :: General, defect, P1)

defect

Tracking

()

RESOLVED FIXED
Tracking Status
e10s + ---
firefox42 --- affected

People

(Reporter: bzbarsky, Assigned: mconley)

References

(Blocks 1 open bug)

Details

When I start my browser, I end up with an unresponsive content process in the middle of trying to send a sync message to its parent.  The parent is using a bunch of CPU (polling on the content?).  Probably relevant is that this is a session with 42 windows and 100-some tabs.

If I then kill the content process and just say to restore the crashed tabs, things work fine...

I tried a debug build.  In a debug build, we spend _forever_ creating windows.  I'm seeing things like "++DOMWINDOW == 101" minutes after starting the browser, with the content process at:

0 <TOP LEVEL> ["chrome://global/content/browser-child.js":599]
    this = [object ContentFrameMessageManager @ 0x13acfea40 (native @ 0x12ddc7160)]

for a long time.  Then we finish up that part and start doing more docshell/window creation, this time while the content process is at a combination of:

0 SyncHandler.init() ["chrome://browser/content/content-sessionStore.js":216]
    this = [object Object]
1 <TOP LEVEL> ["chrome://browser/content/content-sessionStore.js":744]
    this = [object ContentFrameMessageManager @ 0x134db58c0 (native @ 0x1396b2740)]

and

0 restoreHistory( = [object Object]) ["chrome://browser/content/content-sessionStore.js":175]
    this = [object Object]
1 MessageListener.receiveMessage( = [object Object]) ["chrome://browser/content/content-sessionStore.js":133]
    this = [object Object]

in terms of JS stack.

Then some of:

0 PageStyleHandler.init() ["chrome://browser/content/tab-content.js":467]
    this = [object Object]
1 <TOP LEVEL> ["chrome://browser/content/tab-content.js":554]
    this = [object ContentFrameMessageManager @ 0x140629320 (native @ 0x1405d8de0)]

and then back to "chrome://global/content/browser-child.js":599.
Blocks: e10s
OK, my debug build never ended up with the unresponsive child process and seems to have managed to restore the session, though this took ~40 minutes (!).
tracking-e10s: --- → ?
Seeing this also. Mac nightly. I have a startup profile that doesn't look particularly helpful.
rnewman, approximately how many windows were there in the session you were attempting to restore?
Flags: needinfo?(rnewman)
Four windows, maybe 60 tabs total.

I also get a spinner and super slow page loads in a new tab (e.g., clicking this link). I got a slow page yellow bar as I waited to leave this comment. Seems related.
Flags: needinfo?(rnewman)
I imagine this will be quite a bit better once we get the sync messages out of sessionstore.
Flags: needinfo?(mconley)
Assignee: nobody → mconley
Priority: -- → P1
Depends on: 1171708, 1177310
Flags: needinfo?(mconley)
Depends on: 1195295
Hey bz,

There have been significant changes to how session store works over the past few days. Specifically, we no longer do any synchronous messaging from the child to the parent when content-sessionStore.js is loaded. Do you still see this hang on a recent Nightly?

(Setting needinfo on myself since bz is on vacation until the new year - will follow-up with him then).
Flags: needinfo?(mconley)
I also think I heard bsmedberg noticing hangs on startup and shutdown... have those gone away now that the CPOWs are gone?
Flags: needinfo?(mconley) → needinfo?(benjamin)
The bug I filed was https://bugzilla.mozilla.org/show_bug.cgi?id=1223388

Things are better; I certainly haven't seen the hard shutdown hangs. But I just today had some very slow or hang during shutdown (restart for updates) but it didn't have the same symptoms, and manually closing some windows eventually caused Firefox to complete shutdown.
Flags: needinfo?(benjamin)
I just tried this again now that bug 1221540 has had a patch landed, and things are definitely much better now.  I haven't done explicit head-to-head comparisons against non-e10s, but it's certainly in the same general ballpark at this point.

Resolving fixed, thanks!
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.