746730 - crash on Galaxy Nexus with abort message: "Framebuffer not complete -- error 0x8cd6, mFBOTextureTarget 0xde1, aRect.width 989, aRect.height 2337"

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Martijn Wargers (dead)]

I can reproduce this crash on the Samsung Galaxy Nexus, Android4.02.
Steps to reproduce: 
- Go to http://moztw.org/foxmosa/game/pairs/
- Tap on the "Play" button on the site (this can be challenging, because the site looks/acts broken in Fennec in all sorts of ways)
- Tap on the cards until Fennec crashes (you need to have some 'successes' with the game)

I was only able to reproduce this on the Samsung Galaxy Nexus, not on the Galaxy SII or the HTC Desire HD (which are both on Android 2.3).

I guess this might be graphics related.

This bug was filed from the Socorro interface and is 
report bp-1c21df4e-50c8-48cf-b038-9927a2120418 .
============================================================= 
0 	libmozalloc.so 	TouchBadMemory 	memory/mozalloc/mozalloc_abort.cpp:68
1 	libmozalloc.so 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:89
2 	dalvik-heap (deleted) 	dalvik-heap @0x7b011f 	
3 	dalvik-mark-stack (deleted) 	dalvik-mark-stack @0x318af40 	
4 	dalvik-heap (deleted) 	dalvik-heap @0xe9d266b 	
5 	dalvik-mark-stack (deleted) 	dalvik-mark-stack @0x32bd273 	
6 	ashmem (deleted) 	ashmem @0x9ff467 	
7 	dalvik-mark-stack (deleted) 	dalvik-mark-stack @0x127802a 	
8 	ashmem (deleted) 	ashmem @0x26a61e 	
9 	ashmem (deleted) 	ashmem @0x306f71 	
10 	ashmem (deleted) 	ashmem @0x39822d 	
11 	ashmem (deleted) 	ashmem @0x848864 	
12 	ashmem (deleted) 	ashmem @0x24ae63 	
13 	dalvik-heap (deleted) 	dalvik-heap @0xba22f70 	
14 	ashmem (deleted) 	ashmem @0x30402a 	
15 	libxul.so 	nsACString_internal::AppendFunc 	nsTSubstring.h:388
16 	libnspr4.so 	FuncStuff 	nsprpub/pr/src/io/prprf.c:1075
17 	libnspr4.so 	fill_n 	nsprpub/pr/src/io/prprf.c:237
18 		@0x63 	
19 	libxul.so 	nsACString_internal::ReplaceASCII 	xpcom/string/src/nsTSubstring.cpp:503
20 	libxul.so 	nsACString_internal::AppendFunc 	nsTSubstring.h:388
21 	libnspr4.so 	FuncStuff 	nsprpub/pr/src/io/prprf.c:1075
22 	libnspr4.so 	dosprintf 	nsprpub/pr/src/io/prprf.c:1060
23 	libnspr4.so 	PR_vsxprintf 	nsprpub/pr/src/io/prprf.c:1105
24 		@0x6235c19e 	
25 	app_process 	app_process@0xcd4 	
26 	libxul.so 	mozilla::layers::LayerManagerOGL::CreateFBOWithTexture 	gfx/layers/opengl/LayerManagerOGL.cpp:1223
27 	libxul.so 	mozilla::layers::ShadowContainerLayerOGL::RenderLayer 	gfx/layers/opengl/ContainerLayerOGL.cpp:215
28 	libxul.so 	mozilla::layers::ShadowContainerLayerOGL::RenderLayer 	gfx/layers/opengl/ContainerLayerOGL.cpp:252
29 	libxul.so 	mozilla::layers::ShadowContainerLayerOGL::RenderLayer 	gfx/layers/opengl/ContainerLayerOGL.cpp:252
30 	libxul.so 	mozilla::layers::ShadowContainerLayerOGL::RenderLayer 	gfx/layers/opengl/ContainerLayerOGL.cpp:252
31 	libxul.so 	mozilla::layers::ShadowContainerLayerOGL::RenderLayer 	gfx/layers/opengl/ContainerLayerOGL.cpp:252
32 	libxul.so 	mozilla::layers::LayerManagerOGL::Render 	gfx/layers/opengl/LayerManagerOGL.cpp:820
33 	libxul.so 	mozilla::layers::LayerManagerOGL::EndTransaction 	gfx/layers/opengl/LayerManagerOGL.cpp:464
34 	libxul.so 	mozilla::layers::LayerManagerOGL::EndEmptyTransaction 	gfx/layers/opengl/LayerManagerOGL.cpp:437
35 	libxul.so 	mozilla::layers::CompositorParent::Composite 	gfx/layers/ipc/CompositorParent.cpp:224
36 	libxul.so 	RunnableMethod<mozilla::layers::CompositorParent, void , Tuple0>::Run 	ipc/chromium/src/base/tuple.h:383
37 	libxul.so 	MessageLoop::RunTask 	ipc/chromium/src/base/message_loop.cc:318
38 	libxul.so 	MessageLoop::DeferOrRunPendingTask 	ipc/chromium/src/base/message_loop.cc:326
39 	libxul.so 	MessageLoop::DoWork 	ipc/chromium/src/base/message_loop.cc:426
40 	libxul.so 	base::MessagePumpDefault::Run 	ipc/chromium/src/base/message_pump_default.cc:23
41 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:208
42 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:201
43 	libxul.so 	base::Thread::ThreadMain 	ipc/chromium/src/base/thread.cc:156
44 	libxul.so 	ThreadFunc 	ipc/chromium/src/base/platform_thread_posix.cc:26
45 	libc.so 	libc.so@0x12c1e 	
46 	libc.so 	libc.so@0x12772

Comment 1

[Scoobidiver (away)]

It's a dupe of bug 705641 but this one has STR.

Comment 2

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I'm not 100 % convinced that it's a dup, considering the STRs in bug 705641 do not cause a crash on android.

Comment 3

[Martijn Wargers (dead)]

Attachment: testcase

This bug nor the other bug can be found with its stacktrace.

Steps to reproduce:
- Pinch zoom in on the testcase as far as possible.

Tested on the Samsung Galaxy Nexus.

Comment 4

[Martijn Wargers (dead)]

I'm hitting this crash all the time during my fuzz testing. It makes it impossible to find other potential crashers.

Comment 5

[Ali Juma [:ajuma]]

I can reproduce this using the test case from Comment 3.

The problem is that ContainerRender (called by ShadowContainerLayerOGL::RenderLayer) is calling LayerManagerOGL::CreateFBOWithTexture with a framebufferRect whose height (2337) is greater than the Galaxy Nexus' maximum texture size (2048).

We shouldn't need a framebufferRect that large; perhaps it's sufficient for us to ensure that the framebufferRect is no larger than the scissor rect.

Comment 7

[Ali Juma [:ajuma]]

(In reply to Ali Juma [:ajuma] from comment #5)
> We shouldn't need a framebufferRect that large; perhaps it's sufficient for
> us to ensure that the framebufferRect is no larger than the scissor rect.

Actually, this won't work, since we might later apply a transform to the framebufferRect before rendering to the screen, so preemptively clipping the framebufferRect to the scissor rect is just wrong.

Here are a couple options we have to avoid crashing:
1) ContainerRender can simply return early (that is, render nothing) when the framebufferRect is larger than the maximum texture size.

2) ContainerRender can clamp the size of the framebufferRect to the maximum texture size.

In other words, we have a choice between rendering nothing, and rendering something that's incorrect (where the magnitude of incorrectness depends on how much we have to shrink the framebufferRect). Either choice seems strictly better than crashing.

Note that we don't seem to be hitting this problem a lot with real-world web content (this crash accounts for only around 0.04% of all crashes on 14.0b3).

Comment 8

[Ali Juma [:ajuma]]

(In reply to Ali Juma [:ajuma] from comment #7)
> Note that we don't seem to be hitting this problem a lot with real-world web
> content (this crash accounts for only around 0.04% of all crashes on 14.0b3).

This is true for mobile, but not on desktop: the OS X version of this crash (Bug 705641, which appears to have the same cause as this bug) is a top-10 crash in Firefox 12, and a top-20 crash in Nightly.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

One approach would be to simply cap the ContainerLayer's temporary buffer at the max texture size, and apply transforms when drawing into and out of the buffer to compensate. This would degrade rendering quality a bit but it would be a lot better than the other alternatives.

I guess we create a super-large layer here because of the code in nsDisplayItem::RecomputeVisibility, where we have special treatment of the position:fixed content's visible region. Though I don't understand why that's computing something larger than the screen size; we do our best to compute the true visible region there.

Comment 16

[Martijn Wargers (dead)]

The testcase from this bug is still crashing in current trunk build on the Galaxy Nexus. Although, it didn't crash easily.

Comment 17

[Kelsey Gilbert [:jgilbert]]

I can reproduce this on my Nexus 7.

Comment 18

[Kelsey Gilbert [:jgilbert]]

Yeah, actually, this is clearly a Layers issue not a GL issue. Layers needs to find a way to deal with the fact that GL framebuffers have real size limitations.

What it seems like the issue here is that we try to create a framebuffer for the entire visible region such that we have full detail at our maximum zoom. This way, for static pages, we can just zoom and pan all we want. 

*If* this is the case, it seems like the only real way to solve it is with tiling.

Comment 19

[Kelsey Gilbert [:jgilbert]]

Regardless, this seems like a Layers issue until we decide on a way forward.

Comment 20

[Scoobidiver (away)]

Is it reproducible in 19.0 now that bug 827170 is fixed?

Comment 21

[Martijn Wargers (dead)]

Seems not to be a problem anymore in the latest Nightly, so marking fixed then by that bug.