1254443 - PROCESS-CRASH | dom/media/test/test_bug879717.html | application crashed [@ mozilla::layers::GLImage::GetAsSourceSurface]

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect, P5)

Description

[JW Wang [:jwwang] [:jw_wang]]

repro steps:
1. apply the patch: https://hg.mozilla.org/try/rev/f66a9245ecbc
2. push to try with the following message: "try: -b d -p android-api-15 -u mochitest-1,mochitest-e10s-1 -t none --try-test-paths mochitest:dom/media"

results:
https://treeherder.mozilla.org/logviewer.html#?job_id=17748429&repo=try

23:34:04     INFO -  Operating system: Android
23:34:04     INFO -                    0.0.0 Linux 2.6.29-gea477bb #1 Wed Sep 26 11:04:45 PDT 2012 armv7l
23:34:04     INFO -  CPU: arm
23:34:04     INFO -       ARMv7 ARM Cortex-A8 features: swp,half,thumb,fastmult,vfpv2,edsp,neon,vfpv3
23:34:04     INFO -       1 CPU
23:34:04     INFO -  Crash reason:  SIGSEGV
23:34:04     INFO -  Crash address: 0x0
23:34:04     INFO -  Process uptime: not available
23:34:04     INFO -  Thread 12 (crashed)
23:34:04     INFO -   0  libxul.so!mozilla::layers::GLImage::GetAsSourceSurface [ScopedGLHelpers.h:dd4fdf82e368 : 223 + 0x0]
23:34:04     INFO -       r0 = 0x5aee50b7    r1 = 0x0f2bfd6b    r2 = 0x0f2bfd6b    r3 = 0x5b9d8570
23:34:04     INFO -       r4 = 0x52afdf54    r5 = 0x00000000    r6 = 0x5b957878    r7 = 0x40534a20
23:34:04     INFO -       r8 = 0x52afdfb4    r9 = 0x5b44cfe0   r10 = 0x52afdf40   r12 = 0x5a280f81
23:34:04     INFO -       fp = 0x61c34c00    sp = 0x52afdee0    lr = 0x5919d503    pc = 0x5919d502
23:34:04     INFO -      Found by: given as instruction pointer in context
23:34:04     INFO -   1  libxul.so!nsLayoutUtils::SurfaceFromElement [nsLayoutUtils.cpp:dd4fdf82e368 : 7277 + 0x5]
23:34:04     INFO -       r4 = 0x52afe160    r5 = 0x52afdfb4    r6 = 0x52afdfb8    r7 = 0x628da000
23:34:04     INFO -       r8 = 0x52afdfac    r9 = 0x5fbc2c50   r10 = 0x00000000    fp = 0x638845e0
23:34:04     INFO -       sp = 0x52afdf90    pc = 0x59edc0e5
23:34:04     INFO -      Found by: call frame info
23:34:04     INFO -   2  libxul.so!nsLayoutUtils::SurfaceFromElement [nsLayoutUtils.cpp:dd4fdf82e368 : 7310 + 0xb]
23:34:04     INFO -       r4 = 0x52afe160    r5 = 0x628da000    r6 = 0x6301f880    r7 = 0x5fc9c6c0
23:34:04     INFO -       r8 = 0x5fbc2c50    r9 = 0x00000012   r10 = 0x52afe2b8    fp = 0x52afe3b8
23:34:04     INFO -       sp = 0x52afe070    pc = 0x59ee5def
23:34:04     INFO -      Found by: call frame info
23:34:04     INFO -   3  libxul.so!mozilla::dom::CanvasRenderingContext2D::DrawImage [CanvasRenderingContext2D.cpp:dd4fdf82e368 : 4590 + 0xf]
23:34:04     INFO -       r4 = 0x5fbc2c00    r5 = 0x52afe134    r6 = 0x00000000    r7 = 0x52afe160
23:34:04     INFO -       r8 = 0x52afe0ec    r9 = 0x52afe2b8   r10 = 0x52afe2b8    fp = 0x52afe3b8
23:34:04     INFO -       sp = 0x52afe098    pc = 0x598208dd
23:34:04     INFO -      Found by: call frame info
23:34:04     INFO -   4  libxul.so!mozilla::dom::CanvasRenderingContext2DBinding::drawImage [CanvasRenderingContext2D.h:dd4fdf82e368 : 224 + 0xb]
23:34:04     INFO -       r4 = 0x52afe324    r5 = 0x00000001    r6 = 0x5fb04900    r7 = 0x52afe2c8
23:34:04     INFO -       r8 = 0x00000000    r9 = 0x7ff00000   r10 = 0x52afe2b8    fp = 0x52afe3b8
23:34:04     INFO -       sp = 0x52afe228    pc = 0x595c97dd
23:34:04     INFO -      Found by: call frame info
23:34:04     INFO -   5  libxul.so!mozilla::dom::GenericBindingMethod [BindingUtils.cpp:dd4fdf82e368 : 2731 + 0x3]
23:34:04     INFO -       r4 = 0x595c9451    r5 = 0x5b7389a4    r6 = 0x52afe318    r7 = 0x00000000
23:34:04     INFO -       r8 = 0x52afe330    r9 = 0x52afe324   r10 = 0x00000000    fp = 0x52afe3b8
23:34:04     INFO -       sp = 0x52afe308    pc = 0x597e4205
23:34:04     INFO -      Found by: call frame info
23:34:04     INFO -   6  0x61a194aa
23:34:04     INFO -       r4 = 0x67b89b40    r5 = 0xffffff88    r6 = 0x64185d74    r7 = 0xffffff88
23:34:04     INFO -       r8 = 0x00002844    r9 = 0x66bea4b0   r10 = 0x00000002    fp = 0x52afe3b8
23:34:04     INFO -       sp = 0x52afe360    pc = 0x61a194ac
23:34:04     INFO -      Found by: call frame info

Comment 1

[Peter Chang[:pchang]]

Vincent, could you have a look?

Comment 2

[Vincent Liu[:vliu]]

Sure! I will look into it.

Comment 3

[Vincent Liu[:vliu]]

It seems the crash happens because GetAsSourceSurface() was called in off main thread.

https://dxr.mozilla.org/mozilla-central/source/gfx/layers/GLImages.cpp#51

I will try to reproduce it locally to see more information.

Comment 4

[JW Wang [:jwwang] [:jw_wang]]

Any update about this bug?

Comment 5

[Vincent Liu[:vliu]]

In current code base, the following try command can reproduce the issue.

try: -b do -p android-api-15 -u mochitest-media,mochitest-media-e10s,mochitest-media-1,mochitest-media-2 -t none

Comment 6

[Vincent Liu[:vliu]]

Adding more log and found the possible clue to cause crash happens.

[1]: https://dxr.mozilla.org/mozilla-central/source/gfx/gl/ScopedGLHelpers.cpp#278
[2]: https://dxr.mozilla.org/mozilla-central/source/gfx/layers/GLImages.cpp#74

Since status got LOCAL_GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT, mComplete didn't have chance set to true. This result cause crash happens in [2].

Comment 7

[Vincent Liu[:vliu]]

From logcat, there was an error message before crash happens.

E/eglCodecCommon( 2225): **** ERROR unknown type 0x0 (glSizeof,72)

I tried to remove [1] and the mochitest didn't crash any more. The above error was disappear. 

[1]: https://dxr.mozilla.org/mozilla-central/source/gfx/layers/GLImages.cpp#79

Comment 8

[Vincent Liu[:vliu]]

I tried to simplify the test case and let it run with only one content. The thing is 

1. Android 4.3 emulator.
   The crash would happens if the image format got from the output of media decoder is SURFACE_TEXTURE.
2. Android 4.3 on real device.
   The crash never happens.

From the above result, it might be a driver issue. I would try to build up newer Android version of emulation to compare.

Comment 9

[Vincent Liu[:vliu]]

By the way, another found is when the data type of uTexUnit in [1] was uniform sampler2D, the crash never happens. 

[1]:https://dxr.mozilla.org/mozilla-central/source/gfx/gl/GLBlitHelper.cpp#164

Comment 10

[Vincent Liu[:vliu]]

Hi Geoff,
Recently I looked into this problem and wants to discuss with you.

1. The avd I fetched was AVDs-armv7a-android-4.3.1_r1-build-2016-05-12.tar.gz. When I run mochitest for this bug, I alway got crash.
2. Based on the result of 1, I tried to use system.img feteched from android sdk release instead of the original one in avd. The mochitest won't crash any more.
   Note that this system.img came from /Users/mozilla/.mozbuild/android-sdk-macosx/system-images/android-18/default/armeabi-v7a/system.img. I got it when 
  I run ./mach bootstrap.
3. In Gecko view, I could see it probably operating gl functions to casue the crash. I also tried to follow the way in Bug 1136634 Comment 10 to narrow down which
   gl libraries to casue this problem but it is hard to me since the libaries I tried has dependency.

Since I didn't see any wrong information in Gecko view, I think it might have problem in driver view. May I know

1. It seems that the *.img in AVD didn't match to sdk release. In my case above, Will you consider sync *.img to sdk release? And how about the concern?
2. Or do you have any suggestion to suggest me? Thanks.

Comment 11

[Geoff Brown [:gbrown]]

That's interesting!

Please run:

adb shell getprop ro.build.fingerprint

against your /Users/mozilla/.mozbuild/android-sdk-macosx/system-images/android-18/default/armeabi-v7a/system.img

I wonder if this is different from the JLS36I version that I patched in bug 1136634.

If we can find a way to improve the AVD, I'm happy to see that happen, and glad to help (but note that I will be away on pto soon). We need to evaluate the overall effect on all the tests though: I don't want to break the tests fixed in bug 1136634, etc.

Comment 12

[Vincent Liu[:vliu]]

(In reply to Geoff Brown [:gbrown] (pto May 28-June 13) from comment #11)
> That's interesting!
> 
> Please run:
> 
> adb shell getprop ro.build.fingerprint
> 
> against your
> /Users/mozilla/.mozbuild/android-sdk-macosx/system-images/android-18/default/
> armeabi-v7a/system.img
> 
> I wonder if this is different from the JLS36I version that I patched in bug
> 1136634.
> 

The ro.build.fingerprint I got:

ro.build.fingerprint=generic/sdk/generic:4.3.1/JB_MR2/1743067:eng/test-keys

It seems that the version is different.

> If we can find a way to improve the AVD, I'm happy to see that happen, and
> glad to help (but note that I will be away on pto soon). We need to evaluate

Yes, I'd noticed you are on pto so taking your time to handle it. :) 

> the overall effect on all the tests though: I don't want to break the tests
> fixed in bug 1136634, etc.

Did you mean you will consider using the AVD I saw in sdk release instead of JLS36I if it won't break all tests fixed in bug 1136634? I am look forward to see it.

Comment 13

[Geoff Brown [:gbrown]]

Thanks Vincent. I filed bug 1276047 but will not be able to look at that before taking time off. I will investigate immediately after the London All Hands. I hope that's okay.

Basically I will update the avd on try and run the full set of Android tests against it: If the new avd does not break any tests, I'll upgrade the avd.


By t

Comment 14

[Geoff Brown [:gbrown]]

...By the way, I notice some other current bugs with GLImage::GetAsSourceSurface in the crash signature. Are you aware of bug 1272876 and bug 1245959? Are they related to this bug?

Comment 15

[Vincent Liu[:vliu]]

(In reply to Geoff Brown [:gbrown] (pto May 28-June 13) from comment #14)
> ...By the way, I notice some other current bugs with
> GLImage::GetAsSourceSurface in the crash signature. Are you aware of bug
> 1272876 and bug 1245959? Are they related to this bug?

It seems that bug 1245959 hit the same crash so I think it worth trying.

Comment 16

[JW Wang [:jwwang] [:jw_wang]]

Hi Vincent,
It's been a month since last update. Is there any progress?

Btw, this bug is gating our media mochitests on Android. We want to fix this bug as soon as possible.

Comment 17

[Vincent Liu[:vliu]]

Hi JW,

Currently this bug has been blocked by Bug 1276047. Please see [1] for more detailed information.

[1] : https://bugzilla.mozilla.org/show_bug.cgi?id=1276047#c7

I will ni? :gbrown for more information.

Comment 18

[JW Wang [:jwwang] [:jw_wang]]

Per bug 1276047 comment 7, IIUC the new image doesn't fix this bug at all.

It looks like the root cause is somewhere else.

Comment 19

[Vincent Liu[:vliu]]

Hi :gbrown,

I can still see different test result by different fingerprint.

1. Run test with the below system.img will cause crash.
ro.build.description=sdk-eng 4.3.1 JLS36I eng.gbrown.20150308.182649 test-keys
ro.build.fingerprint=generic/sdk/generic:4.3.1/JLS36I/eng.gbrown.20150308.182649:eng/test-keys

2. Run test with the below system.img won't cause crash.
ro.build.description=sdk-eng 4.3.1 JB_MR2 1743067 test-keys
ro.build.fingerprint=generic/sdk/generic:4.3.1/JB_MR2/1743067:eng/test-keys

The above two system.img are all download 

It seems not sync the result you did in [1]. Does it possible you can try the system.img I used in local? If possible, how should I pass the file to you? Thanks 


[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1276047#c7


It seem

Comment 20

[Geoff Brown [:gbrown]]

(In reply to Vincent Liu[:vliu] from comment #19)
> I can still see different test result by different fingerprint.
> 
> 1. Run test with the below system.img will cause crash.
> ro.build.description=sdk-eng 4.3.1 JLS36I eng.gbrown.20150308.182649
> test-keys
> ro.build.fingerprint=generic/sdk/generic:4.3.1/JLS36I/eng.gbrown.20150308.
> 182649:eng/test-keys
> 
> 2. Run test with the below system.img won't cause crash.
> ro.build.description=sdk-eng 4.3.1 JB_MR2 1743067 test-keys
> ro.build.fingerprint=generic/sdk/generic:4.3.1/JB_MR2/1743067:eng/test-keys

To be clear: You see a different test result (crash vs no crash and TEST-PASS?) for test_bug879717? Is that running locally, on your own computer? With mach? Do you run just the single test, or the dom/media directory, or...? (None of these distinctions may be important, but I'd like to start by doing just what you do.)

> The above two system.img are all download 

Sorry, I don't understand. What do you mean?

> It seems not sync the result you did in [1]. Does it possible you can try
> the system.img I used in local? If possible, how should I pass the file to
> you? Thanks 

Can you put your system.img on people.mozilla.org? Or dropbox or something like that?

Comment 21

[Vincent Liu[:vliu]]

(In reply to Geoff Brown [:gbrown] (PTO Sept 7-12) from comment #20)
> (In reply to Vincent Liu[:vliu] from comment #19)
> > I can still see different test result by different fingerprint.
> > 
> > 1. Run test with the below system.img will cause crash.
> > ro.build.description=sdk-eng 4.3.1 JLS36I eng.gbrown.20150308.182649
> > test-keys
> > ro.build.fingerprint=generic/sdk/generic:4.3.1/JLS36I/eng.gbrown.20150308.
> > 182649:eng/test-keys
> > 
> > 2. Run test with the below system.img won't cause crash.
> > ro.build.description=sdk-eng 4.3.1 JB_MR2 1743067 test-keys
> > ro.build.fingerprint=generic/sdk/generic:4.3.1/JB_MR2/1743067:eng/test-keys
> 
> To be clear: You see a different test result (crash vs no crash and
> TEST-PASS?) 

Different result. crash vs no crash but ends up test fail.

for test_bug879717? Is that running locally, on your own
> computer? 

I run it in local on my own computer.

With mach? Do you run just the single test, or the dom/media
> directory, or...? 

Single test by ./mach mochitest dom/media/test/test_bug879717.html

(None of these distinctions may be important, but I'd like
> to start by doing just what you do.)
> 
> > The above two system.img are all download 
> 
> Sorry, I don't understand. What do you mean?
> 

The only change I did for different test result just changing system.img. Those images are download from google and not make by myself. 

> > It seems not sync the result you did in [1]. Does it possible you can try
> > the system.img I used in local? If possible, how should I pass the file to
> > you? Thanks 
> 
> Can you put your system.img on people.mozilla.org? Or dropbox or something
> like that?

Sure. I can put my image into the place you can catch it. Once I have done with it, I will let you know.

Comment 22

[Vincent Liu[:vliu]]

Hi :gbrown,

Last week I'd sent a mail to you for the place where I put Android image to test. Did you see the mail. Looking forward to your reply after test. Thanks

Comment 23

[Geoff Brown [:gbrown]]

Sorry for the delay; I have just returned from some time off. I do see your email and have downloaded the "no-crash" image.

However, I cannot download "crashed-image/system.img" - I think you need to change the permissions on that file.

I should be able to try the images this week.

Comment 24

[Vincent Liu[:vliu]]

Hi :gbrown,

I have changed the permission for the "crashed-image/system.img". You can catch it again. Really thanks for your help.

Comment 25

[Geoff Brown [:gbrown]]

I ran test_bug879717 (only) against each image on my laptop and I confirmed your results: using "crashed-image", the test consistently crashes; using the "no-crash" image, the test does not crash (but it still fails).

I also enabled test_bug879717 and ran the mochitest-media tests on try with each image. Again, I confirmed your results: using "crashed-image", the test consistently crashes; using the "no-crash" image, the test does not crash (but it still fails).


Both of your system.img files are identical to the files I was testing earlier; I think I misunderstood or was confused about what change to expect earlier -- sorry about that. I see now that changing the system.img makes a consistent and positive change to test_bug879717 (it does not crash).

I am still hesitant to update the system.img used for automated tests. The only difference between the crash/no-crash images *should* be the change of https://bugzilla.mozilla.org/show_bug.cgi?id=1136634#c10; I am reluctant to revert this seemingly simple and logical fix. Do you have any idea what it is about the system.img that causes the crash?

Comment 26

[Vincent Liu[:vliu]]

(In reply to Geoff Brown [:gbrown] from comment #25)
> I ran test_bug879717 (only) against each image on my laptop and I confirmed
> your results: using "crashed-image", the test consistently crashes; using
> the "no-crash" image, the test does not crash (but it still fails).
> 
> I also enabled test_bug879717 and ran the mochitest-media tests on try with
> each image. Again, I confirmed your results: using "crashed-image", the test
> consistently crashes; using the "no-crash" image, the test does not crash
> (but it still fails).
> 
> 
> Both of your system.img files are identical to the files I was testing
> earlier; I think I misunderstood or was confused about what change to expect
> earlier -- sorry about that. I see now that changing the system.img makes a
> consistent and positive change to test_bug879717 (it does not crash).
> 
> I am still hesitant to update the system.img used for automated tests. The
> only difference between the crash/no-crash images *should* be the change of
> https://bugzilla.mozilla.org/show_bug.cgi?id=1136634#c10; I am reluctant to
> revert this seemingly simple and logical fix. Do you have any idea what it
> is about the system.img that causes the crash?

Hi :gbrown,

I am afraid I got no idea to know what happens in system.img. It is harder debugging because I don't have symbol for driver. The only clue I saw in Gecko had inputted in Comment 6.

Is it possible to have a newer image for fixing both crash(this and  https://bugzilla.mozilla.org/show_bug.cgi?id=1136634#c10)?

Comment 27

[Geoff Brown [:gbrown]]

(In reply to Vincent Liu[:vliu] from comment #26)
> Is it possible to have a newer image for fixing both crash(this and 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1136634#c10)?

I don't think so.

If I get the latest Android source for the 4.3 branch, it should correspond to the "no-crash" image, but it should also correspond to the source I started with for bug 1136634 -- if I apply my fix, we'll just end up with the "crashed-image" again.

Comment 28

[Vincent Liu[:vliu]]

(In reply to Geoff Brown [:gbrown] from comment #27)
> (In reply to Vincent Liu[:vliu] from comment #26)
> > Is it possible to have a newer image for fixing both crash(this and 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1136634#c10)?
> 
> I don't think so.
> 
> If I get the latest Android source for the 4.3 branch, it should correspond
> to the "no-crash" image, but it should also correspond to the source I
> started with for bug 1136634 -- if I apply my fix, we'll just end up with
> the "crashed-image" again.

Do you mean the latest Android source for the 4.3 branch release from Google won't cause the crash for dom/media/test/test_bug879717.html? If so, I think the fix in bug 1136634 causes the side effect for this crash. We should have someone to look into bug 1136634 to see what's going on. How do you think?

Comment 29

[Geoff Brown [:gbrown]]

(In reply to Vincent Liu[:vliu] from comment #28)
> Do you mean the latest Android source for the 4.3 branch release from Google
> won't cause the crash for dom/media/test/test_bug879717.html? 

Yes. (I haven't actually built and tested that branch, except with the fix from bug 1136634 applied, but it has the same label as the "no-crash" image we have been testing.)

> If so, I think
> the fix in bug 1136634 causes the side effect for this crash. We should have
> someone to look into bug 1136634 to see what's going on. How do you think?

That's fine with me.

Comment 30

[Vincent Liu[:vliu]]

(In reply to Geoff Brown [:gbrown] from comment #27)
> (In reply to Vincent Liu[:vliu] from comment #26)
> > Is it possible to have a newer image for fixing both crash(this and 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1136634#c10)?
> 
> I don't think so.
> 
> If I get the latest Android source for the 4.3 branch, it should correspond
> to the "no-crash" image, but it should also correspond to the source I
> started with for bug 1136634 -- if I apply my fix, we'll just end up with
> the "crashed-image" again.

Can you have a more description about how to apply your fix in bug 1136634 based on the latest Android source for the 4.3 branch? Did you just updating like [1]? What version(fingerprint) of these libraries came from?

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1136634#c10

Comment 31

[Vincent Liu[:vliu]]

Attachment: medai-test-fail.log

I tried to run test_bug879717.html on no "no-crash" image in my local, the detailed fail message showed below.

NFO | automation.py | Application pid: 843
 5:59.34 LOG: None INFO SimpleTest START
 5:59.87 TEST_START: None dom/media/test/test_bug879717.html
 7:20.62 LOG: None INFO Started Wed Sep 28 2016 20:28:57 GMT-0700 (PDT) (1475119737.588s)
 8:02.93 LOG: None INFO [finished 320x240.ogv-0] remaining= seek-short.webm-1
 8:09.51 LOG: None INFO [finished seek-short.webm-1] remaining= vp9-short.webm-2
 9:17.92 LOG: None INFO [finished vp9-short.webm-2] remaining= gizmo-short.mp4-3
 9:27.03 LOG: None INFO [finished gizmo-short.mp4-3] remaining= 
10:20.40 LOG: None INFO Finished at Wed Sep 28 2016 20:31:57 GMT-0700 (PDT) (1475119917.369s)
10:20.50 LOG: None INFO Running time: 179.895s
10:27.10 TEST_END: None Harness OK. Subtests passed 78/82. Unexpected 4
v3 (Stream of 320x240.ogv) should have gotten the 'loadeddata' event callback
-----------------------------------------------------------------------------
Expected PASS, got FAIL
    startTest/checkFinished@dom/media/test/test_bug879717.html:100:5
    startTest/onended@dom/media/test/test_bug879717.html:109:5

v3 (Stream of seek-short.webm) should have gotten the 'loadeddata' event callback
---------------------------------------------------------------------------------
Expected PASS, got FAIL
    startTest/checkFinished@dom/media/test/test_bug879717.html:100:5
    startTest/onended@dom/media/test/test_bug879717.html:109:5

v3 (Stream of vp9-short.webm) should have gotten the 'loadeddata' event callback
--------------------------------------------------------------------------------
Expected PASS, got FAIL
    startTest/checkFinished@dom/media/test/test_bug879717.html:100:5
    startTest/onended@dom/media/test/test_bug879717.html:109:5

v3 (Stream of gizmo-short.mp4) should have gotten the 'loadeddata' event callback
---------------------------------------------------------------------------------
Expected PASS, got FAIL
    startTest/checkFinished@dom/media/test/test_bug879717.html:100:5
    startTest/onended@dom/media/test/test_bug879717.html:109:5

Since this media crash is a regression of fix on Bug 1136634, I will try to input comment to make it fixed. After that, maybe filing a new bug to track test fail.

Comment 32

[Geoff Brown [:gbrown]]

(In reply to Vincent Liu[:vliu] from comment #30)
> (In reply to Geoff Brown [:gbrown] from comment #27)
> > (In reply to Vincent Liu[:vliu] from comment #26)
> > > Is it possible to have a newer image for fixing both crash(this and 
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1136634#c10)?
> > 
> > I don't think so.
> > 
> > If I get the latest Android source for the 4.3 branch, it should correspond
> > to the "no-crash" image, but it should also correspond to the source I
> > started with for bug 1136634 -- if I apply my fix, we'll just end up with
> > the "crashed-image" again.
> 
> Can you have a more description about how to apply your fix in bug 1136634
> based on the latest Android source for the 4.3 branch? Did you just updating
> like [1]? What version(fingerprint) of these libraries came from?
> 
> [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1136634#c10

[1] is the definitive record of how of apply the fix for bug 1136634. I could re-phrase it:

 - get the Android source code
 - apply the 2-line fix to frameworks/native/opengl/libs/EGL/Loader.cpp
 - build Android according to the instructions at https://source.android.com/source/requirements.html
 - run the emulator and patch system.img with the new libEGL.so using the procedure shown in [1]

According to [1], I started with the source for JLS36I, which is android-4.3.1_r1.

Comment 33

[Vincent Liu[:vliu]]

Current status after discussed with :gbrown on IRC.

1. The tag JLS36I is the latest 4.3 to get the source. Based on this code base, plus fix in [1], it fixed  bug 1136634.  But running test_bug879717.html causes crash.

   [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1136634#c10

2. An Android image released from SDK  with fingerprint in [2] won't cause test_bug879717.html but test fail. After talked with :gbrown, he didn't find any tag to get the source to apply fix for bug 1136634. For this, I will take time to find out possible tag for JB_MR2. 

   [2]: ro.build.fingerprint=generic/sdk/generic:4.3.1/JB_MR2/1743067:eng/test-keys

Comment 34

[Vincent Liu[:vliu]]

Hi :gbrown,

I found the following link involving branch information for Android release. In this link, I also saw jb-mr2-release. It is possible the code base we used JB_MR2 from SDK release. Maybe you can also get the source by this tag. How do you think?

https://android.googlesource.com/platform/frameworks/native/+refs

Comment 35

[Geoff Brown [:gbrown]]

That doesn't seem to work:

gbrown@mozpad:~/aosp$ repo init -u https://android.googlesource.com/platform/manifest -b jb-mr2-release
fatal: Couldn't find remote ref refs/heads/jb-mr2-release

fatal: Couldn't find remote ref refs/heads/jb-mr2-release
fatal: cannot obtain manifest https://android.googlesource.com/platform/manifest


Do you know how to use it?

Comment 36

[Vincent Liu[:vliu]]

(In reply to Geoff Brown [:gbrown] from comment #35)
> That doesn't seem to work:
> 
> gbrown@mozpad:~/aosp$ repo init -u
> https://android.googlesource.com/platform/manifest -b jb-mr2-release
> fatal: Couldn't find remote ref refs/heads/jb-mr2-release
> 
> fatal: Couldn't find remote ref refs/heads/jb-mr2-release
> fatal: cannot obtain manifest
> https://android.googlesource.com/platform/manifest
> 
> 
> Do you know how to use it?

It is ok to me trying repo init -u https://android.googlesource.com/platform/manifest -b jb-mr2-dev. I also can't fetch the code by jb-mr2-dev. Would you please try our tests on this branch? Thanks

Comment 37

[Geoff Brown [:gbrown]]

I pulled branch android-4.3.1_r1, which gave me a reported build id of JLS36I, as expected. I built that branch without modification, installed the system.img in the existing "4.3" avd, and tested dom/media/test/test_bug879717.html - it crashed. That suggests that the crash is not caused by the fix in bug 1136634 - good news!

I have now pulled branch jb-mr2-dev, which gives me a reported build id of JB_MR2 - great! I will build that overnight and test tomorrow...

Comment 38

[Geoff Brown [:gbrown]]

I pulled jb-mr2-dev, built and installed it, but had trouble using the emulator with those images. The primary issue is that adb won't connect. 'adb devices' shows the emulator running, but 'adb shell' exits immediately reporting either 'error: connect' or 'error: protocol fault (no status)'. I don't see any unexpected warnings or errors from the kernel or the emulator. Also, Android sometimes does not complete booting.

Comment 39

[Sylvestre Ledru [:Sylvestre]]

Decreasing the priority as no update for the last 2 years on this bug.
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage 
about the priority meaning.

Comment 40

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:bhood, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 41

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 42

[Geoff Brown [:gbrown]]

Most dom/media/test mochitests are now enabled and running reliably.

Also, this crash was happening on Android 4.3 -- no longer supported.