It's #7 top crasher in 10.0b2 on Mac OS X.

Can you please post a crash link?

One comment says: "User Comments crashes every time I try to acces the website ultipro.com" There are two kinds of stack traces: * Firefox 10.0beta: Frame Module Signature [Expand] Source 0 XUL mozilla::gl::GLContext::UploadSurfaceToTexture gfx/thebes/GLContext.cpp:1910 1 XUL mozilla::layers::CairoImageOGL::SetData gfx/layers/opengl/ImageLayerOGL.cpp:800 2 XUL nsImageFrame::GetContainer layout/generic/nsImageFrame.cpp:1277 3 XUL nsDisplayImage::GetContainer layout/generic/nsImageFrame.cpp:1216 4 XUL mozilla::::ContainerState::PopThebesLayerData layout/base/FrameLayerBuilder.cpp:952 5 XUL mozilla::::ContainerState::Finish layout/base/FrameLayerBuilder.cpp:1601 6 XUL mozilla::FrameLayerBuilder::BuildContainerLayerFor layout/base/FrameLayerBuilder.cpp:1806 7 XUL nsDisplayOwnLayer::BuildLayer layout/base/nsDisplayList.cpp:1860 8 XUL mozilla::::ContainerState::ProcessDisplayItems layout/base/FrameLayerBuilder.cpp:1379 9 XUL mozilla::::ContainerState::ProcessDisplayItems layout/base/FrameLayerBuilder.cpp:1331 10 XUL mozilla::::ContainerState::ProcessDisplayItems layout/base/FrameLayerBuilder.cpp:1331 11 XUL mozilla::FrameLayerBuilder::BuildContainerLayerFor layout/base/FrameLayerBuilder.cpp:1800 12 XUL nsDisplayList::PaintForFrame layout/base/nsDisplayList.cpp:598 13 XUL nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:1700 14 XUL PresShell::Paint layout/base/nsPresShell.cpp:5475 ... * Firefox 11.0a2 and 12.0a1: Frame Module Signature [Expand] Source 0 XUL mozilla::gl::GLContext::UploadSurfaceToTexture gfx/gl/GLContext.cpp:1946 1 XUL mozilla::layers::CairoImageOGL::SetData gfx/layers/opengl/ImageLayerOGL.cpp:800 2 XUL mozilla::imagelib::RasterImage::GetImageContainer image/src/RasterImage.cpp:966 3 XUL nsDisplayImage::GetContainer layout/generic/nsImageFrame.cpp:1222 4 XUL mozilla::::ContainerState::PopThebesLayerData layout/base/FrameLayerBuilder.cpp:976 5 XUL mozilla::FrameLayerBuilder::BuildContainerLayerFor layout/base/FrameLayerBuilder.cpp:1626 6 XUL nsDisplayOwnLayer::BuildLayer layout/base/nsDisplayList.cpp:1864 7 XUL mozilla::::ContainerState::ProcessDisplayItems layout/base/FrameLayerBuilder.cpp:1404 8 XUL mozilla::::ContainerState::ProcessDisplayItems layout/base/FrameLayerBuilder.cpp:1355 9 XUL mozilla::::ContainerState::ProcessDisplayItems layout/base/FrameLayerBuilder.cpp:1355 10 XUL mozilla::FrameLayerBuilder::BuildContainerLayerFor layout/base/FrameLayerBuilder.cpp:1836 11 XUL nsDisplayList::PaintForFrame layout/base/nsDisplayList.cpp:602 12 XUL nsLayoutUtils::PaintFrame layout/base/nsLayoutUtils.cpp:1714 13 XUL PresShell::Paint layout/base/nsPresShell.cpp:5511 ... More reports at: https://crash-stats.mozilla.com/report/list?signature=mozilla%3A%3Agl%3A%3AGLContext%3A%3AUploadSurfaceToTexture

I can't reproduce this on a nightly with OSX 10.7 - AMD Radeon 6770M

Some things that could help diagnosing this: - a correlation report on the GPU and version of OS X - a time when we started seeing these crashes I don't know how to get either of these pieces of information out socorro.

Technically the signature has been around since we shipped 4.0 but very low volume. I found only 2 of these crashes (4.0 and 5.0.1) in the month of Sept. I checked Oct and we only had 4 from (2011/10/09 through 2011/11/09). It increases to 21 in the 2 week period between (2011/11/09 and 2011/11/23). Looking more closely most of the crashes from that period are in 11.0a1 and 10.0a2 so it might be something that was checked into the trunk just before the cutover? The oldest build I during that period with the crash is the 11.0a1 - 20111111031514 and it's consistently higher in volume after that. Let me check on a correlation report.

The based on that the best guess I have for a change that could cause this would be bug 697990. "Clean up GLES-specific workarounds for GL_UNPACK_ROW_LENGTH."

I'm able to reproduce this crash now when loading http://www.sdge.com/index.shtml on OS X 10.6.8. I will come up with more details soon.

The site sdge.com doesn't always crash for me. The crash is better reproducible with the URL as mentioned in comment 0. So here are my steps: 1. Create a fresh profile or delete the cache via the CRH dialog 2. Make sure Flash is enabled (I have 10.2.153.1 installed) 3. Open ultipro.com After step 3 the browser always crashes for me. But only if the cache has been cleared before or we restore a session after a crash. The regression for me starts between Firefox 9.0.1 and Firefox 10b1. Even we have reports for 9.0.1 listed on crash-stats I can't reproduce it with this version. It could be something different. I will now work on the regression range.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #6) > The based on that the best guess I have for a change that could cause this > would be bug 697990. "Clean up GLES-specific workarounds for > GL_UNPACK_ROW_LENGTH." I don't think so. I have tested a build from Nov 7th, 8th, and 9th, and all three are showing this crash. Interestingly the crash signature is not the same for Nightly builds. In my case it's changing to 'XUL@0xf6ea2a' Nightly crash report: bp-bfb1e9a0-84fd-42aa-b0b7-120712120110

Regressed between the builds 2011-10-26-03 and 2011-10-27-03: WORKS: http://hg.mozilla.org/mozilla-central/rev/cc66accc8181 FAILS: http://hg.mozilla.org/mozilla-central/rev/4bb7c983d589 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cc66accc8181&tochange=4bb7c983d589 Given that it highly correlates to the cache, I would assume that bug 689008 is related for this regression. CC'ing some parties who worked on that bug.

The crash also happens for Aurora and Nightly builds, so we should track it on all branches.

I have tried to run a debug tinderbox build but a build like the one below doesn't even start on 10.6.8. :/ http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-macosx64-debug/1326186259/

(In reply to Henrik Skupin (:whimboo) from comment #9) > In my case it's changing to 'XUL@0xf6ea2a' This crash signature happens in 10.0a1/20111107031104. As this kind of signatures changes with each build, if you want to track it in Socorro, you need to add a bunch of XUL crash signatures.

(In reply to Henrik Skupin (:whimboo) from comment #10) > Regressed between the builds 2011-10-26-03 and 2011-10-27-03: > > WORKS: http://hg.mozilla.org/mozilla-central/rev/cc66accc8181 > FAILS: http://hg.mozilla.org/mozilla-central/rev/4bb7c983d589 > > Pushlog: > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=cc66accc8181&tochange=4bb7c983d589 Looking at the stacks, this crash is happening when aSurface is null in GLContext::UploadSurfaceToTexture. In the given regression range, my best guess is Bug 695275.

I still can't reproduce this unfortunately. This should fix the issue though.

Comment on attachment 587461 [details] [diff] [review] Check the result of GetFrame I haven't checked whether the GetImageContainer callers handle failure, but this is obviously correct.

(In reply to Matt Woodrow (:mattwoodrow) from comment #15) > I still can't reproduce this unfortunately. > > This should fix the issue though. Not sure if it is related but I also can't reproduce the crash with a debug build of Firefox build on 10.6.8. Once a build with the patch is included has been made available I will run a test against it.

Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0a1) Gecko/20120112 Firefox/12.0a1 Alex, this is a top crasher for us for Firefox 10. It would be great to see backports to Aurora and Beta.

Comment on attachment 587461 [details] [diff] [review] Check the result of GetFrame [Approval Request Comment] Regression caused by (bug #): User impact if declined: Testing completed (on m-c, etc.): Risk to taking this patch (and alternatives if risky):

Matt, can you do the assessment in #21?

[Approval Request Comment] Regression caused by (bug #): Bug 695275 User impact if declined: Frequent crashes. Testing completed (on m-c, etc.): Baked on m-c for 2 days Risk to taking this patch (and alternatives if risky): Very low risk, just checks for an error condition within imagelib, and reverts to the previous codepath if ti finds one.

Comment on attachment 587461 [details] [diff] [review] Check the result of GetFrame [Triage Comment] Deemed very low risk, and resolves a top crasher. Approved for Aurora/Beta.

The existing patch doesn't apply on mozilla-beta because some code was moved. This is the equivalent patch, but in the old location.

Comment on attachment 589052 [details] [diff] [review] Check the result of GetFrame - mozilla-beta version [Triage Comment] Approved for beta - please land ASAP so that this get's into today's build of beta 5.

(In reply to Matt Woodrow (:mattwoodrow) from comment #29) > https://hg.mozilla.org/releases/mozilla-beta/rev/4e02e7bfd700 Matt, please also update the tracking flag once the patch has been landed. Thanks.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20100101 Firefox/10.0 Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20100101 Firefox/10.0 Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0 Verfied Fixed on Firefox 10b6 with a clean profile using the page mentioned in Comment 7(http://www.sdge.com/index.shtml). The page from Comment 2 doesn't load for me. I also looked in Socorro and I did not find any crashes on Firefox 10 beta after the fix has landed (the last crashes are on Firefox 10b4). Is there another page I can use to verify this fix, so that I could mark this as verified on beta?

Both websites have been changed and I can't get Firefox to crash. So lets assume this is fixed. Thanks Simona.

When trying to verify this on Firefox 11 beta 6 I found 4 crash-stats with the signature: [@ mozilla::layers::SurfaceToTexture ] https://crash-stats.mozilla.com/report/index/4957bfc5-c6b0-4ed3-94dc-12a372120209 https://crash-stats.mozilla.com/report/index/42fd982a-31ed-4fc3-9752-ee8f92120217 https://crash-stats.mozilla.com/report/index/61723033-0e17-4094-b5d9-917fc2120221 https://crash-stats.mozilla.com/report/index/616c56f2-cb4c-4f5a-bcb9-32bd42120221 Do you think these crashes could be triggered by another bug or should this bug be reopened?

(In reply to Simona B [QA] from comment #33) > Do you think these crashes could be triggered by another bug or should this > bug be reopened? File a new bug because the stack is different.

(In reply to Scoobidiver from comment #34) > (In reply to Simona B [QA] from comment #33) > > Do you think these crashes could be triggered by another bug or should this > > bug be reopened? > File a new bug because the stack is different. Where can I find the stack for a crash report in the Socorro interface?

(In reply to Simona B [QA] from comment #35) > Where can I find the stack for a crash report in the Socorro interface? It's named Crashing Thread. Compare it to the ones in comment 2. They are different.

Filled Bug 730314. Based on Comment 34 marking this as verified on Firefox 11 beta 4. Thanks Scoobidiver for the guidance!