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)
Core
General
Tracking
()
RESOLVED
FIXED
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.
Reporter | ||
Comment 1•9 years ago
|
||
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 (!).
Assignee | ||
Updated•9 years ago
|
tracking-e10s:
--- → ?
Comment 2•9 years ago
|
||
Seeing this also. Mac nightly. I have a startup profile that doesn't look particularly helpful.
Assignee | ||
Comment 4•9 years ago
|
||
rnewman, approximately how many windows were there in the session you were attempting to restore?
Flags: needinfo?(rnewman)
Comment 5•9 years ago
|
||
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)
Assignee | ||
Comment 6•9 years ago
|
||
I imagine this will be quite a bit better once we get the sync messages out of sessionstore.
Flags: needinfo?(mconley)
Updated•9 years ago
|
Assignee: nobody → mconley
Priority: -- → P1
Assignee | ||
Updated•9 years ago
|
Assignee | ||
Comment 7•9 years ago
|
||
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)
Assignee | ||
Comment 8•9 years ago
|
||
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)
Comment 9•9 years ago
|
||
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)
Reporter | ||
Comment 10•8 years ago
|
||
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.
Description
•