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)

22 Branch
x86_64
macOS
defect
Not set
critical

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
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.
If you disable the explicit NS_RUNTIMEABORT(), we flash a black frame, but then settle into the correct result.
It appears fTexImage2d call causes GL_INVALID_VALUE error just before the crash.
Keywords: reproducible
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.
Wait... this bug is BACK ?!?!
(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.
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.
...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
Ouch... bug 716859 is the obvious candidate there.
Blocks: 716859
(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.
If it can regress easily, there should be tests in testsuite this time.
(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.
(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.
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 ]
(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.
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
Depends on: 804936
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.