Closed Bug 1254443 Opened 9 years ago Closed 2 years ago

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

Categories

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

Product:
Core
Component:
Graphics: Layers
Platform:
ARM
Android
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: jwwang, Assigned: gbrown)

References

Details

(Whiteboard: [gfx-noted])

Attachments

(1 file)

medai-test-fail.log
121.41 KB, text/x-log
Details
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
Whiteboard: [gfx-noted]
Vincent, could you have a look?
Flags: needinfo?(vliu)
Sure! I will look into it.
Flags: needinfo?(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.
Assignee: nobody → vliu
Any update about this bug?
Flags: needinfo?(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
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].
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
Flags: needinfo?(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.
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
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.
Flags: needinfo?(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.
Flags: needinfo?(gbrown)
(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.
Flags: needinfo?(gbrown)
Depends on: 1276047
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
Flags: needinfo?(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?
(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.
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.
Flags: needinfo?(vliu)
Severity: normal → critical
Priority: -- → P1
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.
Flags: needinfo?(vliu)
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.
Flags: needinfo?(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
Flags: needinfo?(vliu) → needinfo?(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?
Flags: needinfo?(gbrown)
(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.
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
Flags: needinfo?(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.
Flags: needinfo?(gbrown)
Flags: needinfo?(gbrown)
Hi :gbrown, I have changed the permission for the "crashed-image/system.img". You can catch it again. Really thanks for your help.
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?
Flags: needinfo?(gbrown)
(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)?
Flags: needinfo?(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.
Flags: needinfo?(gbrown)
(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?
Flags: needinfo?(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.
Flags: needinfo?(gbrown)
(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
Flags: needinfo?(gbrown)
Attached file 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.
(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.
Flags: needinfo?(gbrown)
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
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
Flags: needinfo?(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?
Flags: needinfo?(gbrown)
(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
Flags: needinfo?(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...
Flags: needinfo?(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.
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.
Priority: P1 → P5
QA Whiteboard: qa-not-actionable

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.

Assignee: vincent.liu1013 → nobody
Flags: needinfo?(bhood)
Flags: needinfo?(bhood)

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.

Severity: critical → --

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

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

Assignee: nobody → gbrown
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: