738188 - crash [@ memcpy | libGLESv2_POWERVR_SGX540_120.so@0x6df6 ] on device rotation soon after startup or following a link from an external application

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Cristian Nicolae (:xti)]

This bug was filed from the Socorro interface and is 
report bp-1bd0eb6e-6c74-40bd-8e58-745ef2120314 .
============================================================= 

Frame 	Module 	Signature [Expand] 	Source
0 	libc.so 	memcpy 	
1 	libGLESv2_POWERVR_SGX540_120.so 	libGLESv2_POWERVR_SGX540_120.so@0x6df6 	
2 	libGLESv2_POWERVR_SGX540_120.so 	libGLESv2_POWERVR_SGX540_120.so@0x8c26 	
3 	libGLESv2_POWERVR_SGX540_120.so 	libGLESv2_POWERVR_SGX540_120.so@0x4b33e 	
4 	libGLESv2_POWERVR_SGX540_120.so 	libGLESv2_POWERVR_SGX540_120.so@0x9aa6 	
5 	dalvik-LinearAlloc (deleted) 	dalvik-LinearAlloc @0x604d2 	
6 	libdvm.so 	dexDataMapAlloc 	
7 	libandroid_runtime.so 	_Z34register_android_opengl_jni_GLES20P7_JNIEnv 	
8 	libdvm.so 	dvmPlatformInvoke 	
9 	dalvik-heap (deleted) 	dalvik-heap @0x282a6 	
10 	libdvm.so 	dvmCallJNIMethod_staticNoRef 	
11 	libdvm.so 	dvmAsmSisterStart 	
12 	libdvm.so 	dvmMterpStd 	
13 	libdvm.so 	dvmInterpret 	
14 	libdvm.so 	dvmCallMethodV 	
15 	libdvm.so 	dvmCallMethod 	
16 	libdvm.so 	dvmDetachCurrentThread 	
17 	libc.so 	__thread_entry 	
18 	libc.so 	pthread_create

Step to reproduce:
1. Open Fennec and rotate the device immediately

Expected result:
No crash should occur after step 1.

Actual result:
This crash occur always after step 1.

--
Firefox 14.0a1 (2012-03-21)
Device: Samsung Nexus S
OS: Android 2.3.6

Comment 1

[Joe Drew (not getting mail)]

(gdb) bt
#0  0x40071b54 in memcpy ()
   from /home/joe/moz-gdb/lib/0149A4550C01701E/system/lib/libc.so
#1  0x5b9e672c in ?? ()
   from /home/joe/moz-gdb/lib/0149A4550C01701E/system/lib/libGLESv2_POWERVR_SGX540_120.so
#2  0x5b9e672c in ?? ()
   from /home/joe/moz-gdb/lib/0149A4550C01701E/system/lib/libGLESv2_POWERVR_SGX540_120.so

"Thread-398" prio=5 tid=12 NATIVE
  | group="main" sCount=1 dsCount=0 obj=0x41939a80 self=0x136ff0
  | sysTid=5108 nice=0 sched=0/0 cgrp=default handle=1741672
  | schedstat=( 0 0 0 ) utm=4 stm=9 core=1
  at android.opengl.GLES20.glDrawArrays(Native Method)
  at org.mozilla.gecko.gfx.SingleTileLayer.draw(SingleTileLayer.java:158)
  at org.mozilla.gecko.gfx.LayerRenderer$Frame.drawBackground(LayerRenderer.java:573)
  at org.mozilla.gecko.gfx.LayerRenderer.onDrawFrame(LayerRenderer.java:274)
  at org.mozilla.gecko.gfx.GLThread$RenderFrameMessage.run(GLThread.java:136)
  at org.mozilla.gecko.gfx.GLThread.run(GLThread.java:71)

Comment 2

[Joe Drew (not getting mail)]

This is not fixed by turning off the use of glTexSubImage2D and using only power-of-two textures, i.e., full Adreno derp mode.

Comment 3

[:Felipe Gomes (needinfo for replies!)]

I get this crash every time Fennec opens following a link from an external application. No device rotation involved (I have the orientation locked to portrait on my phone).

This is a Nexus S running Android 2.3.6

Here are some of the crash reports I've sent:
https://crash-stats.mozilla.com/report/index/bp-8832785c-d7bb-45a4-9e1a-28ca32120322
https://crash-stats.mozilla.com/report/index/bp-e7cd43fd-8a90-4878-936e-6eba22120324
https://crash-stats.mozilla.com/report/index/bp-3e45a2a2-648c-4130-9653-e968e2120324

Comment 4

[Jeff Muizelaar [:jrmuizel]]

(In reply to Joe Drew (:JOEDREW!) from comment #1)
> 573)
>   at org.mozilla.gecko.gfx.LayerRenderer.onDrawFrame(LayerRenderer.java:274)
>   at org.mozilla.gecko.gfx.GLThread$RenderFrameMessage.run(GLThread.java:136)
>   at org.mozilla.gecko.gfx.GLThread.run(GLThread.java:71)

This looks wrong:

    public void onDrawFrame(GL10 gl) {
        RenderContext pageContext = createPageContext(mView.getController().getViewportMetrics());
        RenderContext screenContext = createScreenContext();
        Frame frame = createFrame(pageContext, screenContext);
        synchronized (mView.getController()) {
            frame.beginDrawing();
            frame.drawBackground();
            frame.drawRootLayer();
            frame.drawForeground();
            frame.endDrawing();
        }   
    }

Notice GL10. My understanding is that this drawing should be driven by the compositor and I'm guessing this code is getting run by accident.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

Attachment: Test patch to fix this

Comment 6

[Kartikaya Gupta (email:[e-mail])]

AIUI, onDrawFrame gets called before gecko comes up, to draw the placeholder image. The GLThread is active during this time, and is shut down when gecko comes up. The idea is that once gecko comes up, onDrawFrame is no longer called; instead the OMTC drives equivalent code by calling drawWindowUnderlay and drawWindowOverlay.

Comment 7

[Jeff Muizelaar [:jrmuizel]]

This seems to be caused by SurfaceChange breaking any future onDrawFrame calls. We don't seem to handle renewing the context at all. I added mController.disposeGLContext(); mController.initGLContext(); to the SizeChange::run() but that doesn't seem to fix it.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

Attachment: Avoid crashing by temporarily disabling the screenshot drawing code

I'll file a followup about turning this back on.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/72a3e44395b2

Comment 10

[Ed Morley [:emorley]]

Please can you set the target milestone when landing on inbound, along the lines of http://blog.bonardo.net/2012/03/23/how-you-can-help-mozilla-inbound-sheriffs-when-pushing :-)

https://hg.mozilla.org/mozilla-central/rev/72a3e44395b2

Comment 11

[Jeff Muizelaar [:jrmuizel]]

(In reply to Ed Morley [:edmorley] from comment #10)
> Please can you set the target milestone when landing on inbound, along the
> lines of
> http://blog.bonardo.net/2012/03/23/how-you-can-help-mozilla-inbound-sheriffs-
> when-pushing :-)
> 
> https://hg.mozilla.org/mozilla-central/rev/72a3e44395b2

Yes, sorry about that.