Closed
Bug 695246
Opened 13 years ago
Closed 13 years ago
Crash in OpenGL when switching or closing tabs
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 696768
People
(Reporter: joe, Assigned: ajuma)
References
Details
(Keywords: crash, Whiteboard: [mobile-crash])
Crash Data
Fennec crashes on my Nexus S whenever I switch tabs or close tabs with GLES layers enabled. Looks like a null pointer dereference. I imagine most of the crashes in Fennec at that address are me using Fennec nightlies.
Reporter | ||
Comment 1•13 years ago
|
||
bp-d34c58fa-0084-4ea5-82e0-8566c2111017 is the most recent example of this crash.
Updated•13 years ago
|
Blocks: opengl-mobile
Updated•13 years ago
|
Assignee | ||
Comment 2•13 years ago
|
||
This happens in the Sept. 8 nightly (and onwards) but not in the Sept. 7 nightly. Also, this doesn't happen with debug builds, and doesn't happen on the Galaxy Tab.
Keywords: regression
Assignee | ||
Comment 3•13 years ago
|
||
Correction: this does indeed happen in the Sept. 7 nightly. In fact, this happens at least as far back as the March 1 nightly.
Assignee: nobody → ajuma
Keywords: regression
Assignee | ||
Comment 4•13 years ago
|
||
This crash is happening inside the call to fTexSubImage2D made by TextureImageEGL::EndUpdate. This crash only happens when the currently bound framebuffer is non-zero. Interestingly, simply adding a call to fCheckFramebufferStatus (but doing nothing with the return value) right before the call to fTexSubImage2D prevents the crash. So why aren't we seeing this crash in debug builds? In debug builds, LayerManagerOGL::CreateFBOWithTexture makes a call to fCheckFramebufferStatus. Making this call also happen in non-debug builds also turns out to be sufficient for preventing the crash. The currently bound framebuffer shouldn't have any effect on a call to fTexSubImage2D, nor should calls to fCheckFramebufferStatus have any effects on subsequent calls to fTexSubImage2D, so we seem to be hitting a driver bug.
Status: NEW → ASSIGNED
Pasting in the Crashing Thread: Crashing Thread Frame Module Signature [Expand] Source 0 libGLESv2_POWERVR_SGX540_120.so libGLESv2_POWERVR_SGX540_120.so@0xe854 1 libGLESv2_POWERVR_SGX540_120.so libGLESv2_POWERVR_SGX540_120.so@0x1d53b 2 libGLESv2_POWERVR_SGX540_120.so libGLESv2_POWERVR_SGX540_120.so@0x1fd37 3 libGLESv2_POWERVR_SGX540_120.so libGLESv2_POWERVR_SGX540_120.so@0x4338b 4 libGLESv2_POWERVR_SGX540_120.so libGLESv2_POWERVR_SGX540_120.so@0x4338b 5 libGLESv2_POWERVR_SGX540_120.so libGLESv2_POWERVR_SGX540_120.so@0x4338b 6 dalvik-heap (deleted) dalvik-heap @0x356fff 7 dalvik-heap (deleted) dalvik-heap @0x556fff 8 dalvik-heap (deleted) dalvik-heap @0x59efff 9 dalvik-heap (deleted) dalvik-heap @0x502fff 10 dalvik-heap (deleted) dalvik-heap @0x366fff 11 dalvik-heap (deleted) dalvik-heap @0x55afff 12 dalvik-heap (deleted) dalvik-heap @0x596fff 13 dalvik-heap (deleted) dalvik-heap @0x4fafff
Updated•13 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•