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.
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.
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.
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...
(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.
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.
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!