Closed Bug 715916 Opened 12 years ago Closed 12 years ago

Crash [@ mozilla::gl::GLContext::UploadSurfaceToTexture ][@ XUL@0xf6ea2a ]

Categories

(Core :: Graphics, defect)

10 Branch
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla12
Tracking Status
firefox10 + verified
firefox11 + verified
firefox12 - verified

People

(Reporter: scoobidiver, Assigned: mattwoodrow)

References

Details

(4 keywords, Whiteboard: [qa!])

Crash Data

Attachments

(2 files)

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
Crash Signature: [@ mozilla::gl::GLContext::UploadSurfaceToTexture ]
Keywords: crash, topcrash
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.
Crash Signature: [@ mozilla::gl::GLContext::UploadSurfaceToTexture ] → [@ mozilla::gl::GLContext::UploadSurfaceToTexture ] [@ XUL@0xf6ea2a ]
Summary: Crash @ mozilla::gl::GLContext::UploadSurfaceToTexture → Crash [@ mozilla::gl::GLContext::UploadSurfaceToTexture ][@ XUL@0xf6ea2a ]
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.
Assignee: nobody → matt.woodrow
Blocks: 695275
I still can't reproduce this unfortunately.

This should fix the issue though.
Attachment #587461 - Flags: review?(joe)
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.
Attachment #587461 - Flags: review?(joe) → review+
(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.
Status: NEW → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/c16d6dc44101
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
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.
Status: RESOLVED → VERIFIED
Whiteboard: [qa+]
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):
Attachment #587461 - Flags: approval-mozilla-beta?
Attachment #587461 - Flags: approval-mozilla-aurora?
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.
Attachment #587461 - Flags: approval-mozilla-beta?
Attachment #587461 - Flags: approval-mozilla-beta+
Attachment #587461 - Flags: approval-mozilla-aurora?
Attachment #587461 - Flags: approval-mozilla-aurora+
The existing patch doesn't apply on mozilla-beta because some code was moved. This is the equivalent patch, but in the old location.
Attachment #589052 - Flags: review?
Attachment #589052 - Flags: approval-mozilla-beta?
Attachment #589052 - Flags: review? → review?(joe)
Attachment #589052 - Flags: review?(joe) → review+
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.
Attachment #589052 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Crash Signature: [@ mozilla::gl::GLContext::UploadSurfaceToTexture ] [@ XUL@0xf6ea2a ] → [@ mozilla::gl::GLContext::UploadSurfaceToTexture ] [@ XUL@0xf6ea2a ] [@ mozilla::layers::SurfaceToTexture ]
OS: Mac OS X → All
Hardware: x86_64 → All
(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.
Keywords: verified-beta
Whiteboard: [qa+] → [qa+][qa!:10][qa!:12]
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!
Whiteboard: [qa+][qa!:10][qa!:12] → [qa!]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: