If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Browser hangs during session restore (in BasicLayerManager code?)

RESOLVED WORKSFORME

Status

()

Firefox
Session Restore
--
major
RESOLVED WORKSFORME
6 years ago
6 years ago

People

(Reporter: Ben Sizer, Unassigned)

Tracking

({qawanted})

8 Branch
x86
Windows 7
qawanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
I loaded up Firefox after earlier closing it successfully, with many tabs in the session (about 30).

Instead of loading all my tabs as expected, Firefox shows all the tabs along the top but hangs with 100% CPU usage when trying to load them.

The interface is entirely unresponsive, including min/max/close buttons. It is apparently not handling Windows messages as right-clicking on it in the taskbar and choosing Close immediately brings up the dialog saying that the app is unresponsive.

No data appears to be lost, per-se; if I close Firefox this way and re-open it, I get the "this is embarrassing" session restore prompt with all tabs listed as expected.

This problem appears to be new, only occurring to me in the last few days. Firefox reports itself as being version 8.00.0000.4309, which I received on the 22nd of October. I have just now updated to 8.00.0000.4316 which exhibits the same problem.

Process Explorer suggests that it is just Firefox's main thread that is using all the CPU, and reports variations on the following call-stacks (presumably missing lots of info or even just incorrect due to lack of debugging information):

 -- 8.00.0000.4309 --
ntkrnlpa.exe!NtBuildNumber+0xef
xul.dll!gfxContext::Rectangle+0x10d50
xul.dll!mozilla::layers::BasicLayerManager::PushGroupWithCachedSurface+0x5de
xul.dll!gfxFont::SetupGlyphExtents+0x5122
xul.dll!mozilla::layers::LayerManagerOGL::`vftable'+0x82658
xul.dll!NS_InvokeByIndex_P+0x1666b

 -- 8.00.0000.4316 --
ntkrnlpa.exe!NtBuildNumber+0xef
xul.dll!gfxFontUtils::GetPrefsFontList+0x4433
xul.dll!gfxCachedTempSurface::Get+0x84b5
xul.dll!mozilla::layers::Layer::Release+0x227b
xul.dll!gfxASurface::SurfaceDestroyFunc+0x2f3e
xul.dll!gfxFontGroup::FontResolverProc+0x4e2
xul.dll!gfxAlphaBoxBlur::Init+0x98a6
xul.dll!gfxTextRunCache::ReleaseTextRun+0xeea
xul.dll!gfxWindowsNativeDrawing::PaintToContext+0x4cdf
xul.dll!gfxWindowsNativeDrawing::PaintToContext+0xa447
xul.dll!gfxMatrix::Reset+0x45c1
xul.dll!gfxMatrix::Reset+0x4468
xul.dll!NS_NewLocalFile_P+0xc17
xul.dll!NS_NewLocalFile_P+0xac4
xul.dll!gfxAlphaBoxBlur::Init+0x6490
xul.dll!gfxFontUtils::ReadCMAPTableFormat4+0x4495

I expect they are a bit bogus but both seem to be related to layout code so it is probably not a coincidence.
Keywords: qawanted
Ben, would you be willing to hunt down which website seems be causing that? You can double or middle click on items about the session restore "embarrassing" page to open that item. If it doesn't hang you can close and move onto the next one.

It doesn't seem to be directly session restore related (since the hang doesn't happen until after restoring & is in gfx). I'm assuming it's a single website, but it could be something in our ui instead.
(Reporter)

Comment 2

6 years ago
Yes, the only reason I marked it as Session Restore was because these tabs/sites all worked fine before I closed the browser.

It's worth noting that I use 3 tab groups, and that I can't individually test the tabs in the 2nd and 3rd groups as they don't appear in the session restore dialog and Firefox hangs before I can switch to a different group on the tab groups page (which never gets as far as rendering its thumbnails). Is there possibly something in sessionstore.js I can edit to make it think I had a different tab group open, so I can try the others?

Of the tabs I could test, which was about 2/3rds of them, I was able to restore each tab individually without problem, using the method you suggested. It's just when I click 'Restore' for the session as a whole, I get the hanging behaviour.
(Reporter)

Comment 3

6 years ago
Still happening with 8.00.0000.4323. Is there anything else I can do to diagnose this? A debug build that might give a more accurate call-stack to Process Monitor?
Sorry for the delay here. Is this still happening Ben?

(In reply to Ben Sizer from comment #2)
> It's worth noting that I use 3 tab groups, and that I can't individually
> test the tabs in the 2nd and 3rd groups as they don't appear in the session
> restore dialog

All tabs should show up in that window, regardless of if they were hidden or not.

> Is there possibly something in sessionstore.js I can edit to make it think I
> had a different tab group open, so I can try the others?

Like I said, they should all be visible, but if you want to edit that file and make everything visible, I think just deleting any "hidden":true instances should do it. I'm not sure if panorama will reconstitute with other data it has.

> Of the tabs I could test, which was about 2/3rds of them, I was able to
> restore each tab individually without problem, using the method you
> suggested. It's just when I click 'Restore' for the session as a whole, I
> get the hanging behaviour.

Weird. Could be that you have some bogus data or phantom window...
(Reporter)

Comment 5

6 years ago
(In reply to Paul O'Shannessy [:zpao] from comment #4)
> Sorry for the delay here. Is this still happening Ben?

And sorry for the delay here also! Shortly after my last post my old computer died, and I've been without a desktop for the last few weeks, and unable to look into this issue further.

Today I got a new Windows 7 64-bit machine, and have just copied the Firefox profile over to a fresh install of FX 8.01, opened it up, and... same thing. Different OS (mostly), different hardware, different graphic drivers, just the same profile and the same symptoms.

I suppose the silver lining is that instead of the hung process taking up 50% of my CPU, the new machine means it only occupies 12.5% of it. ;)

> All tabs should show up in that window, regardless of if they were hidden or not.

You're right, it does appear to show all of them. In which case, I managed to open all of them ok before, just not when it is done automatically.

The only difference I see this time around is that the call stack, as reported by Process Monitor, seems to show slightly different locations. Here are 3 examples (it changes every time I view it, as I suppose you'd expect from code that is repeatedly executing).


user32.dll+0x19bef
xul.dll!?SnapTransform@Layer@layers@mozilla@@IAE?AVgfx3DMatrix@@ABV4@ABUgfxRect@@PAUgfxMatrix@@@Z+0xc38
xul.dll!??1gfxFontGroup@@UAE@XZ+0x4c2a
xul.dll!?Round@gfxRect@@QAEXXZ+0x7882

user32.dll+0x19bef
xul.dll!??1gfxFontGroup@@UAE@XZ+0x4cee
xul.dll!??1gfxFontGroup@@UAE@XZ+0x4c2a
xul.dll!?Round@gfxRect@@QAEXXZ+0x7882

user32.dll+0x19bef
xul.dll!NS_InvokeByIndex_P+0x13ccee
xul.dll!??1gfxFontGroup@@UAE@XZ+0x4cee
xul.dll!NS_InvokeByIndex_P+0x13ccee
xul.dll!??1gfxFontGroup@@UAE@XZ+0x4c2a
xul.dll!?Round@gfxRect@@QAEXXZ+0x7882


Not sure if that's any help, but I'm willing to try debug builds and/or submit logs if someone will point me in the right direction.
(Reporter)

Updated

6 years ago
OS: Windows XP → Windows 7
(Reporter)

Comment 6

6 years ago
The good news is, this is fixed for me on 9.01 - the same session loads up just fine, and I have quit out and re-opened it once since then without any problems.

Comment 7

6 years ago
Verified on:
Mozilla/5.0 (Windows NT 6.1; rv:12.0a1) Gecko/20120108 Firefox/12.0a1

I tried to reproduce Ben's problem several times. No freezes or crashes occurred but, after crashing Firefox with 34 tabs with the nightly tester tools and restoring the session, the firefox.exe process took 45-50% of the CPU and about 500 MB of memory.
Given that it's been a while and it's all working, let's call this WFM. Thanks for reporting and following up, Ben!
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.