Closed Bug 587186 Opened 14 years ago Closed 13 years ago

Access violation causing hang/crash/freeze in Firefox 4.0 beta 2 and 3 (not beta 1) [@ layers::BasicLayerManager::PushGroupWithCachedSurface]

Categories

(Core :: Graphics, defect)

1.9.2 Branch
x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 591358

People

(Reporter: beesting.moz, Unassigned)

Details

(Keywords: crash)

Crash Data

Attachments

(1 file, 2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8

After having been using Fx4b1 without problems for a while, I first upgraded to beta 2. Then it kept hanging a lot. Beta 3 seems a bit better, but still also keeps hanging.

The strange this is that it seems (to me as a user) that it's more like the UI (including web content) is unresponsive, rather than the app being completely frozen. That is because it still does respond to the min/max/close buttons (I can actually close one of the Fx windows that are open, after a kill and restore, it'll still be closed) and also no breakpad or Windows crash reporter is being shown (the windows doesn't even become bright dimmed when clicking on it, as win7 normally does for frozen apps).

After it's hanging, it never comes back alive. I can only kill it and start the app again, after which it'll work for a few minutes (even up to a few hours) again. Furthermore, it hangs pretty much randomly. Most of the time it hangs when I'm not even using it (it's open in the background) and I haven't even touched it for at least a few minutes. As said, it all started since beta 2 (because of the layers change? As that's also in the stack trace, but I'm just guessing here).

Hopefully it can be fixed before the final. :) (And if there's an error in my submission, I'm sorry, this is my first.)

Reproducible: Sometimes

Steps to Reproduce:
1. Open Firefox 4.0 beta 2 or beta 3
2. Open a lot of tabs (or restore a session with lots of tabs)
3. Just wait a while, not even necessary to touch the browser
Actual Results:  
The browser completely hangs (except for the min/max/close buttons)

Expected Results:  
It doesn't hang.

Default theme.

From the stack trace:
(2d0c.1dd0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
xul!mozilla::layers::BasicLayerManager::PushGroupWithCachedSurface+0x12b:
50fd019b 09460c          or      dword ptr [esi+0Ch],eax ds:002b:0000000c=????????
please install and use a 32bit version of windbg, i don't have good instructions for using the 64bit version of windbg, so the results are generally painful.
Component: General → Graphics
Product: Firefox → Core
QA Contact: general → thebes
Summary: Access violation causing hang/crash/freeze in Firefox 4.0 beta 2 and 3 (not beta 1) (in layers::BasicLayerManager::PushGroupWithCachedSurface) → Access violation causing hang/crash/freeze in Firefox 4.0 beta 2 and 3 (not beta 1) [@ layers::BasicLayerManager::PushGroupWithCachedSurface]
Version: unspecified → 1.9.2 Branch
Keywords: crash
My bad, I did use the download link from how to get a stack trace for firefox (on DMO), but apparently when you click on the download link on that page, Microsoft then transfers you to an automatic downloader that downloads the x64 version instead. :(

I've just downloaded the previous version of windbg (http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.11.1.404.msi), as that appears to be 32-bit at least. If someone has a better link, please let me know.

As soon as it hangs again (which probably won't take days), I'll try and post a new stack trace.

BTW, don't know if this helps, and I'm not a 100% sure, but I feel that this most commonly happens when the browser isn't focused. It seems like most of the time it's hanging when I alt-tab back to it.
Please feel free to update the DMO article. I have a horrible time w/ wiki's, so that page updates when i get someone else to update it :(.
Attached file Stack trace #2 (x86 version) (obsolete) —
Ok, it just crashed again. This time with the x86 windbg attached. See the attached stack trace and please let me know if it's ok this time. (If it is, then I'll also try to update the wiki.)
Did that the first time, unfortunately forgot it the last time. So here's another stack trace. Hopefully everything's OK this time. If not, please let me know! :)
Attachment #465850 - Attachment is obsolete: true
Attachment #466049 - Attachment is obsolete: true
Because it's been a while now, I was wondering if I can somehow be of any more assistance in getting this bug fixed. If so, please let me know.

And is it perhaps somehow related to bug #591358 ? I didn't test the betas for a while because of the crashes, so can't tell if it perhaps got fixed through another bug fix. But if it helps if I test anything, I'd like to know. :)
Does this still happen in nightlies?
Crash Signature: [@ layers::BasicLayerManager::PushGroupWithCachedSurface]
This looks like the same bug as 591358, resolving it as a duplicate.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: