crash in mozilla::layers::LayerManagerOGL::CreateFBOWithTexture with abort message: "Framebuffer not complete -- error 0x8cd6, mFBOTextureTarget 0xde1, aRect.width 4608, aRect.height 3072"

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
6 years ago
5 years ago

People

(Reporter: scoobidiver, Assigned: milan)

Tracking

({crash, regression, reproducible})

22 Branch
x86_64
Mac OS X
crash, regression, reproducible
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox21 unaffected, firefox22 unaffected)

Details

(crash signature, URL)

(Reporter)

Description

6 years ago
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.
Blocks: 846759
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.
(Reporter)

Updated

6 years ago
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.
(Reporter)

Comment 11

6 years ago
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.
(Reporter)

Updated

6 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 ]
(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
(Reporter)

Updated

6 years ago
Duplicate of this bug: 849040
(Reporter)

Updated

6 years ago
Depends on: 804936
(Reporter)

Comment 17

6 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
Last Resolved: 6 years ago
status-firefox22: affected → unaffected
Resolution: --- → WORKSFORME
No longer blocks: 846759
You need to log in before you can comment on or make changes to this bug.