Closed
Bug 847283
Opened 12 years ago
Closed 12 years ago
crash in mozilla::layers::LayerManagerOGL::CreateFBOWithTexture with abort message: "Framebuffer not complete -- error 0x8cd6, mFBOTextureTarget 0xde1, aRect.width 4608, aRect.height 3072"
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox21 | --- | unaffected |
firefox22 | --- | unaffected |
People
(Reporter: scoobidiver, Assigned: milan)
References
()
Details
(Keywords: crash, regression, reproducible)
Crash Data
Bug 705641 fixed in 20.0 is back in 22.0a1. It's #6 top browser crasher in the trunk on Mac OS X.
It first showed up in 22.0a1/20130221072044 but is discontinuous across builds. The regression range might be:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=401b967b2dfc&tochange=702d2814efbf
A comment talks about zooming in Google Maps.
Signature mozalloc_abort(char const*) | NS_DebugBreak_P | _ZZL13nsEscapeCountPKc12nsEscapeMaskPmE8hexChars More Reports Search
UUID dce1aacf-e0ce-45e0-bcae-133a62130303
Date Processed 2013-03-03 22:06:10
Uptime 33
Last Crash 39 seconds before submission
Install Age 4.4 hours since version was first installed.
Install Time 2013-03-03 17:43:38
Product Firefox
Version 22.0a1
Build ID 20130303030835
Release Channel nightly
OS Mac OS X
OS Version 10.8.2 12C3006
Build Architecture amd64
Build Architecture Info family 6 model 58 stepping 9
Crash Reason EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Crash Address 0x0
App Notes
AdapterVendorID: 0x8086, AdapterDeviceID: 0x 166GL Context? GL Context+ GL Layers? GL Layers+ xpcom_runtime_abort(###!!! ABORT: Framebuffer not complete -- error 0x8cd6, mFBOTextureTarget 0xde1, aRect.width 4608, aRect.height 3072: file ../../../../gfx/layers/opengl/LayerManagerOGL.cpp, line 1545)
Processor Notes sp-processor09.phx1.mozilla.com_2952:2008; exploitablity tool: ERROR: unable to analyze dump
EMCheckCompatibility True
Adapter Vendor ID 0x8086
Adapter Device ID 0x 166
Frame Module Signature Source
0 libmozalloc.dylib mozalloc_abort mozalloc_abort.cpp:30
1 XUL NS_DebugBreak_P xpcom/base/nsDebugImpl.cpp:387
2 XUL _ZZL13nsEscapeCountPKc12nsEscapeMaskPmE8hexChars
3 GLEngine gleDrawArraysOrElements_ExecCore
4 libsystem_c.dylib pthread_mutex_unlock
5 GeForceGLDriver GeForceGLDriver@0xb4f48
6 libmozglue.dylib arena_run_split _string.h:80
7 firefox main browser/app/nsBrowserApp.cpp:351
8 libsystem_c.dylib tiny_malloc_from_free_list
9 libsystem_c.dylib szone_malloc_should_clear
10 libmozglue.dylib arena_malloc jemalloc.c:1714
11 GeForceGLDriver GeForceGLDriver@0x1
12 XUL CMMFCertOrEncCertTemplate
13 libnspr4.dylib PR_vsxprintf nsprpub/pr/src/io/prprf.c:1073
14 libnspr4.dylib libnspr4.dylib@0x5ac0
15 XUL XUL@0x12784a0
16 XUL nsACString_internal::AppendPrintf xpcom/string/src/nsTSubstring.cpp:772
17 XUL nsACString_internal::Replace obj-firefox/x86_64/dist/include/nsCharTraits.h:395
18 libsystem_c.dylib pthread_mutex_unlock
19 XUL CMMFCertOrEncCertTemplate
20 XUL CMMFCertOrEncCertTemplate
21 XUL mozilla::layers::LayerManagerOGL::CreateFBOWithTexture gfx/layers/opengl/LayerManagerOGL.cpp:1545
22 XUL mozilla::layers::ContainerLayerOGL::RenderLayer gfx/layers/opengl/ContainerLayerOGL.cpp:236
23 XUL mozilla::layers::Layer::CalculateScissorRect gfx/layers/Layers.cpp:722
24 GLEngine glScissorArrayv_Exec
25 XUL mozilla::layers::ContainerLayerOGL::RenderLayer gfx/layers/opengl/ContainerLayerOGL.cpp:274
More reports at:
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*%29+|+NS_DebugBreak_P+|+_ZZL13nsEscapeCountPKc12nsEscapeMaskPmE8hexChars
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*%29+|+Abort
Assignee | ||
Comment 1•12 years ago
|
||
To reproduce:
www.car2go.com, set to Toronto, click on where am I, then zoom out. Assert in the nightly debug on OSX 10.8.
Assignee | ||
Comment 2•12 years ago
|
||
If you disable the explicit NS_RUNTIMEABORT(), we flash a black frame, but then settle into the correct result.
Assignee | ||
Comment 3•12 years ago
|
||
It appears fTexImage2d call causes GL_INVALID_VALUE error just before the crash.
Reporter | ||
Updated•12 years ago
|
Keywords: reproducible
Reporter | ||
Updated•12 years ago
|
Comment 4•12 years ago
|
||
Yes, that's because this invalid framebuffer error is caused by trying to use too high texture sizes, and then attaching that to a framebuffer object. As you note, the original error is purely at the level of texture dimensions here. The fix is to not try to use texture sizes greater than MAX_TEXTURE_SIZE.
Comment 5•12 years ago
|
||
Wait... this bug is BACK ?!?!
Assignee | ||
Comment 6•12 years ago
|
||
(In reply to Benoit Jacob [:bjacob] from comment #5)
> Wait... this bug is BACK ?!?!
Yup. Crashes in nightly and 19, perhaps others I haven't tried.
Comment 7•12 years ago
|
||
19 is expected, as we didn't backport the fix, right? What I'd like to know is why it regressed in 22. Need to take the window given in comment 0 and use it in hg log -r A..B gfx/ to filter gfx changes.
Comment 8•12 years ago
|
||
...which gives:
bjacob:/hack/mozilla-central$ hg log -r 401b967b2dfc..702d2814efbf gfx/
changeset: 122392:e8c8d9373eba
user: Matt Brubeck <mbrubeck@mozilla.com>
date: Tue Feb 19 17:06:18 2013 -0800
summary: Back out dd103ec4c44b through fba3a342a530 because of B2G test failures on a CLOSED TREE
changeset: 122399:ea8b11062c07
user: Karl Tomlinson <karlt+@karlt.net>
date: Wed Feb 20 11:04:00 2013 +1300
summary: b=788935 remove unused no-op virtual GLContext::WindowDestroyed() r=vlad
changeset: 122451:b46c006a7696
user: Jeff Gilbert <jgilbert@mozilla.com>
date: Wed Feb 13 15:26:24 2013 -0800
summary: Bug 716859 - Streaming GLContext buffers (doublebuffering, etc) - r=bjacob,jrmuizel,vlad
changeset: 122460:f04919e7789f
user: Ryan VanderMeulen <ryanvm@gmail.com>
date: Wed Feb 20 10:01:20 2013 -0500
summary: Backed out changeset b46c006a7696 (bug 716859) and changeset 6a14e4c15aa6 (bug 841836) for B2G test failures on a CLOSED TREE.
changeset: 122502:82747d694e7a
user: Jeff Gilbert <jgilbert@mozilla.com>
date: Wed Feb 13 15:26:24 2013 -0800
summary: Bug 716859 - Streaming GLContext buffers (doublebuffering, etc) - r=bjacob,jrmuizel,vlad
Assignee | ||
Comment 10•12 years ago
|
||
(In reply to Benoit Jacob [:bjacob] from comment #4)
> Yes, that's because this invalid framebuffer error is caused by trying to
> use too high texture sizes, and then attaching that to a framebuffer object.
> As you note, the original error is purely at the level of texture dimensions
> here. The fix is to not try to use texture sizes greater than
> MAX_TEXTURE_SIZE.
In my crash, GetMaxTextureSize() returns 16384, and the texture is 4322x1630.
Reporter | ||
Comment 11•12 years ago
|
||
If it can regress easily, there should be tests in testsuite this time.
Comment 12•12 years ago
|
||
(In reply to Milan Sreckovic [:milan] from comment #10)
> (In reply to Benoit Jacob [:bjacob] from comment #4)
> > Yes, that's because this invalid framebuffer error is caused by trying to
> > use too high texture sizes, and then attaching that to a framebuffer object.
> > As you note, the original error is purely at the level of texture dimensions
> > here. The fix is to not try to use texture sizes greater than
> > MAX_TEXTURE_SIZE.
>
> In my crash, GetMaxTextureSize() returns 16384, and the texture is 4322x1630.
Ah, that's interesting as it means that it's not the same bug as before and my above theory is wrong.
Comment 13•12 years ago
|
||
(In reply to Benoit Jacob [:bjacob] from comment #12)
> (In reply to Milan Sreckovic [:milan] from comment #10)
> > (In reply to Benoit Jacob [:bjacob] from comment #4)
> > > Yes, that's because this invalid framebuffer error is caused by trying to
> > > use too high texture sizes, and then attaching that to a framebuffer object.
> > > As you note, the original error is purely at the level of texture dimensions
> > > here. The fix is to not try to use texture sizes greater than
> > > MAX_TEXTURE_SIZE.
> >
> > In my crash, GetMaxTextureSize() returns 16384, and the texture is 4322x1630.
>
> Ah, that's interesting as it means that it's not the same bug as before and
> my above theory is wrong.
It sounds like we should do proper max FBO+Texture framebuffer completeness tests as part of layers init.
Reporter | ||
Updated•12 years ago
|
Crash Signature: [@ mozalloc_abort(char const*) | NS_DebugBreak_P | _ZZL13nsEscapeCountPKc12nsEscapeMaskPmE8hexChars]
[@ mozalloc_abort(char const*) | Abort] → [@ mozalloc_abort(char const*) | NS_DebugBreak_P | _ZZL13nsEscapeCountPKc12nsEscapeMaskPmE8hexChars ]
[@ mozalloc_abort(char const*) | Abort ]
Assignee | ||
Comment 14•12 years ago
|
||
(In reply to Benoit Jacob [:bjacob] from comment #12)
> (In reply to Milan Sreckovic [:milan] from comment #10)
> > (In reply to Benoit Jacob [:bjacob] from comment #4)
> > > Yes, that's because this invalid framebuffer error is caused by trying to
> > > use too high texture sizes, and then attaching that to a framebuffer object.
> > > As you note, the original error is purely at the level of texture dimensions
> > > here. The fix is to not try to use texture sizes greater than
> > > MAX_TEXTURE_SIZE.
> >
> > In my crash, GetMaxTextureSize() returns 16384, and the texture is 4322x1630.
>
> Ah, that's interesting as it means that it's not the same bug as before and
> my above theory is wrong.
I think your theory is correct, I can confirm that the invalid parameter is the width > 4096. I can believe that the maximum overall (cairo?) texture size is 16k, but I'm also pretty sure that the maximum HW texture size on my machine is 4k, which is why we can't create an FBO. So, the question is - what is GetMaxTextureSize meant to return? It seems that the value is too optimistic, and that this is really a non-integrated graphics version of bug 737182.
However, in the car2go.com STR, zooming out, the step when we crash, is the first time we call LayerManagerOGL::CreateFBOWithTexture. Is that expected? In other words, the first draw (on open) and second (on "where am i") don't go into that function, but zooming out does.
Assignee | ||
Comment 15•12 years ago
|
||
I may have lied here, it appears we go into the Intel specific code. In that case, this really is the same as bug 737182, but we only correct the value for max texture in one place.
Assignee: nobody → milan
Reporter | ||
Comment 17•12 years ago
|
||
Crashes stopped after 22.0a1/20130307. The working range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ee4879719f78&tochange=cb432984d5ce
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•