Closed Bug 1099356 Opened 11 years ago Closed 10 years ago

[Video] The video app crashes when opening the app or trying to play a video

Categories

(Firefox OS Graveyard :: Vendcom, defect)

Product:
Firefox OS Graveyard
Component:
Vendcom
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected, b2g-master affected)

Status:
RESOLVED DUPLICATE of bug 1101826
Tracking Flags:
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- affected
b2g-master --- affected

People

(Reporter: sarsenyev, Unassigned)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: [2.1-exploratory-3][POVB], b2g-crash)

Crash Data

Attachments

(4 files)

log1114.txt
27.61 KB, text/plain
Details
big_buck_bunny_trailer_480p_baseline.mp4
4.72 MB, video/mp4
Details
temporary patch - Make easier to reproduce the problem
1.97 KB, patch
Details | Diff | Splinter Review
Video
4.94 MB, video/mp4
Details
Attached file log1114.txt —
This bug was filed from the Socorro interface and is report bp-cd99ae93-474a-48df-bf89-4316e2141114. ============================================================= crash in libstagefright.so@0xdcd8e Description: 3 crashes happened when opened the video app or used the slider to slide a video Repro Steps: 1) Update a Flame device to BuildID: 20141114040205 2) Open the "Video" app 3) Play a video 4) If the step two didn't work play with the slider forward/backward and play/pause Actual: The video app crashes Expected: The video app doesn't crash Flame 2.2 Device: Flame 2.2 Master (319mb)(Kitkat Base)(Shallow Flash) BuildID: 20141114040205 Gaia: 1e300eac2e56d98ad51d414766d031db7d33221f Gecko: bbb68df450c2 Version: 36.0a1 (2.2) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Notes: The first crash occurred when opened the video app, the other when used the slider Repro frequency:repro rate 70% 3/5 See attached: Youtube video clip, logcat
The issue reproduces on 2.1 and 2.0 Flame builds. The crash occurs when opening a video app or moving a slider "Flame 2.1 Device: Flame 2.1 (319mb)(Kitkat Base)(Shallow Flash) BuildID: 20141114001204 Gaia: af6533781356acc62b0f40c9e040aa5b47d3b709 Gecko: 551326425826 Version: 34.0 (2.1) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0" "Flame 2.0 Device: Flame 2.0 (319mb)(Kitkat Base)(Shallow Flash) Build ID: 20141114000200 Gaia: 28991b28d54fc4ef8112c8fa678bf20f9faca8c8 Gecko: 62294be0fc98 Version: 32.0 (2.0) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0"
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → affected
Flags: needinfo?(dharris)
Keywords: regression
Keywords: regression
I filed bug 1100116 for a similar crash I saw. I think this is Core::Video/Audio bug.
[Blocking Requested - why for this release]: This is a crash with a high repro rate. Nominating this bug to block 2.0.
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris)
Hi Vincent: Please help check if any clue on this bug!! Thanks!! Shawn
Flags: needinfo?(vliu)
[Blocking Requested - why for this release]: [Blocking Requested - why for this release]: [Triage] worth to further check but not in 2.0, considering current timing of 2.0 plus the way to repro. it. Nom. to 2.1.
blocking-b2g: 2.0? → 2.1?
Loop wchi to look into it.
Flags: needinfo?(wchi)
FYI, I couldn't repro this bug in latest 2.1 branch: Gaia-Rev 1b231b87aad384842dfc79614b2a9ca68a4b4ff3 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/95fbd7635152 Build-ID 20141118001204 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental 40 FW-Date Tue Oct 21 15:59:42 CST 2014 Bootloader L1TC10011880 I used video files of various length, and used sliders/play/pause, but could not see the crash.
I was able to repro this bug on a couple devices with the latest branches 2.2, 2.1 and 2.0 I was moving the slider from beginning to the end back and forth a couple times and the crash occured
(In reply to sarsenyev from comment #8) > I was able to repro this bug on a couple devices with the latest branches > 2.2, 2.1 and 2.0 > I was moving the slider from beginning to the end back and forth a couple > times and the crash occured Please attach the video that you used for testing. Moving to Core ->Audio/Video for investigation... 11-14 12:54:05.248: A/OMXCodec(10238): frameworks/av/media/libstagefright/OMXCodec.cpp:4264 CHECK_EQ( (int)mPortStatus[kPortIndexOutput],(int)ENABLED) failed: 4 vs. 0 11-14 12:54:05.618: E/OMXNodeInstance(203): !!! Observer died. Quickly, do something, ... anything...
Component: Gaia::Video → Video/Audio
Product: Firefox OS → Core
I used a random video, I took a different device, recorded a video clip with the "Camera" played a random video file and was able to repro the crash
FYI, I was able to repro. Here is the parsed callstack === Crash reason: SIGABRT Crash address: 0x4528 Thread 24 (crashed) 0 libc.so!tgkill + 0xc 1 libc.so!pthread_kill [pthread_kill.cpp : 49 + 0xb] 2 libc.so!raise [raise.cpp : 32 + 0x9] 3 libc.so!__libc_android_abort [abort.cpp : 55 + 0x3] 4 libc.so!abort + 0x6 5 libcutils.so!__android_log_assert [logd_write.c : 261 + 0x3] 6 libstagefright.so!android::OMXCodec::onCmdComplete(OMX_COMMANDTYPE, unsigned long) [OMXCodec.cpp : 2730 + 0x2d] 7 libstagefright.so!android::OMXCodec::onEvent(OMX_EVENTTYPE, unsigned long, unsigned long) [OMXCodec.cpp : 2621 + 0x7] 8 libstagefright.so!android::OMXCodec::on_message(android::omx_message const&) [OMXCodec.cpp : 2333 + 0xb] 9 libstagefright.so!android::OMXCodecObserver::onMessage(android::omx_message const&) [OMXCodec.cpp : 139 + 0x7] 10 libmedia.so!android::BnOMXObserver::onTransact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int) [IOMX.cpp : 947 + 0x9] 11 libbinder.so!android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int) [Binder.cpp : 108 + 0x11] 12 libbinder.so!android::IPCThreadState::executeCommand(int) [IPCThreadState.cpp : 1074 + 0x11] 13 libbinder.so!android::IPCThreadState::getAndExecuteCommand() [IPCThreadState.cpp : 436 + 0x5] 14 libbinder.so!android::IPCThreadState::joinThreadPool(bool) [IPCThreadState.cpp : 490 + 0x5] 15 libbinder.so!android::PoolThread::threadLoop() [ProcessState.cpp : 67 + 0xb] 16 libutils.so!android::Thread::_threadLoop(void*) [Threads.cpp : 767 + 0x7] 17 libutils.so!thread_data_t::trampoline(thread_data_t const*) [Threads.cpp : 95 + 0x3] 18 libc.so!__thread_entry [pthread_create.cpp : 105 + 0x6] 19 libc.so!pthread_create [pthread_create.cpp : 224 + 0x16] ===
Flags: needinfo?(wchi)
Repro Steps 1. open video app 2. select the video clip and pause it 3. drag slider to the end (back and forth if not crash) repeat #3 I can repro this issue on .mp4, .3gpp files easily and fail to repro in .webm
Flags: needinfo?(vliu)
Hi Blake According to the log and callstack, it looks like we have some problem on buffer ref-counting. Can you comment on this? Thanks.
Flags: needinfo?(bwu)
This bug seems a dup of Bug 110045.
Assignee: nobody → sotaro.ikeda.g
This bug sees to have 2 types of crashes. They seems to happen by different causes. - [1] The crash happens because of input port status check. - [2] The crash happens because of output port status check.
Depends on: 1101742
(In reply to Sotaro Ikeda [:sotaro] from comment #15) > - [2] The crash happens because of output port status check. This seems to be fixed by bug 1101742.
(In reply to Sotaro Ikeda [:sotaro] from comment #16) > (In reply to Sotaro Ikeda [:sotaro] from comment #15) > > > - [2] The crash happens because of output port status check. > > This seems to be fixed by bug 1101742. Are you sure? I was about to mark this as a dupe of bug 1100459 which now has a patch attached to it, as from my testing this is a bug on libstagefright?
Flags: needinfo?(sotaro.ikeda.g)
Err sorry, I misread the CHECK. First glance told me it was the same as the one I was dealing with but the log shows otherwise.
Flags: needinfo?(sotaro.ikeda.g)
Depends on: 1101826
(In reply to Sotaro Ikeda [:sotaro] from comment #15) > This bug sees to have 2 types of crashes. They seems to happen by different > causes. > - [1] The crash happens because of input port status check. Bug 1101826 is created for it. It happens because of caf's OMX IL component implementation.
(In reply to wchi from comment #13) > Hi Blake > > According to the log and callstack, it looks like we have some problem on > buffer ref-counting. > Can you comment on this? > > Thanks. Thanks to Sotaro, he has done some clear and good analysis and I have the same opinions as well :-) One thing I am wondering is the crash at my hand (already with the fixed patch in bug 1101742) only happens when I dragged the slider to the end. If I didn't drag to the end, this crash would not happen. If the reminding root cause is caf's OMX IL component implementation, why that only happens for the case that drags the slider to the end. Currently it is a mystery to me.
Flags: needinfo?(bwu)
We discussed this in triage and QA confirmed its pretty easy to hit so blocking this and its dependencies for 2.0
blocking-b2g: 2.1? → 2.0+
> If the reminding root cause is caf's OMX IL component implementation, why > that only happens for the case that drags the slider to the end. Currently > it is a mystery to me. It just seems easily happen when input is reached to EOS. When I analyzed it, the crash of Bug 1101826 always happen, when Seek to EOS happen 2 times in a row. When it happens, hw omx ls does not have a buffer to return. Such situation could happen only when input stream is EOS. Bug 1059661 changed the way of seeking at EOS. Therefore, the crash could happen since b2g v2.0.
(In reply to Sotaro Ikeda [:sotaro] from comment #22) > >When it happens, hw omx ls does not have a buffer to return. Such > situation could happen only when input stream is EOS. Correction: hw omx have only one buffer that does not have valid data, but have only EOS flag. The buffer is in the middle of returning to client side.
This bug is waiting Bug 1101826 fix. Bug 1101826 is POVB bug.
Can we check if it can be reproduced with 18D now?
Keywords: qawanted
The repro rate is about 1 in ~70 attempts on latest Flame 2.2 + v188-1 base. I only repro'ed once in all attempts. (1 attempt = doing a set of step 4 of original STR, mimicking the actions in the reporter's video) On latest Flame 2.1 + v188-1 base the repro rate is higher but still not high enough. It's about 3 in ~30 attempts. ------------- With the above low repro rate established, I tested with v18D base and here's the results: Bug reproduced 0 in ~70 attempts in the following: Device: Flame 2.2 Master BuildID: 20141230154859 Gaia: 26d479f0fccb7174e06255121e4e938c1b280d67 Gecko: 88037f94b7d7 Version: 37.0a1 (2.2 Master) Firmware: V18D User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0 Bug reproduced 3 in ~15 attempts in the following: Device: Flame 2.1 BuildID: 20141226091635 Gaia: 73be51f998031f06db0cd660c0e388fa621c9f4c Gecko: ea426e47bfc4 Version: 34.0 (2.1) Firmware: V18D User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 ------ Conclusion: repro rate has dropped significantly lower in 2.2, and base image v18D does NOT make a difference in repro rates between 2.1/2.2 branches.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
(In reply to Pi Wei Cheng [:piwei] from comment #26) > The repro rate is about 1 in ~70 attempts on latest Flame 2.2 + v188-1 base. > I only repro'ed once in all attempts. (1 attempt = doing a set of step 4 of > original STR, mimicking the actions in the reporter's video) > > On latest Flame 2.1 + v188-1 base the repro rate is higher but still not > high enough. It's about 3 in ~30 attempts. > It might be side effect of Bug 1104411 fix. How to seek is changed.
(In reply to Sotaro Ikeda [:sotaro] from comment #27) > (In reply to Pi Wei Cheng [:piwei] from comment #26) > > The repro rate is about 1 in ~70 attempts on latest Flame 2.2 + v188-1 base. > > I only repro'ed once in all attempts. (1 attempt = doing a set of step 4 of > > original STR, mimicking the actions in the reporter's video) > > > > On latest Flame 2.1 + v188-1 base the repro rate is higher but still not > > high enough. It's about 3 in ~30 attempts. > > > > It might be side effect of Bug 1104411 fix. How to seek is changed. I confirmed that reverting Bug 1104411 make easier to reproduce the problem.
Just to note, this bug is more easily reproducible (4/5) in today's master: Crash log: https://crash-stats.mozilla.com/report/index/9ac02c02-bdde-4aac-810f-1d2b32150224
status-b2g-master: --- → affected
After talking to :sotaro offline, I learned that this bug is dependent on bug 1101826, which is pending response from qc. Because a number of enhancements are made to the seek operation in past couple of months, this bug became quite easily reproducible in 2.2 and master. For bug 1101826, sotaro suggested that we might need to fork the branch and provide the fix ourselves. Since it's a longstanding bug (2.0 blocker) that can cause app to crash in a common use case, should we move this to 2.2 blocker? ni'ing bhavana FYI.
Flags: needinfo?(bbajaj)
Hi Norry, qawanted for Woodduck 2.0M, Dolphin 2.1S and 2.2 Nexus 5. Thanks!
Flags: needinfo?(fan.luo)
Keywords: qawanted
Hi Sotaro, looks like bug 1101826 got de-nomed based on the feedback from qc from 2.0. Is it possible that we can do a workaround on this for 2.2?
Flags: needinfo?(sotaro.ikeda.g)
This bug is actually dup of bug 1101826. gecko side could not do workaround for it. discussion about the crash is separated to bug 1101826 and this bug. It seems not good. It is better to dupe this bug to bug 1101826.
Flags: needinfo?(sotaro.ikeda.g)
Attached video Video —
Hi Reporter, This problem cannot be repro on latest build of Woodduck 2.0, Dolphin 2.1S(512m) and 2.2 Nexus 5, Could you help to confirm whether the STR in my video is correct? Thanks! See attachment: Video.MP4 Fail rate: 0/20 Woodduck 2.0 build: Build ID 20150306050313 Gaia Revision ca46abde35cda645a1c5dfa80e111c400feabdba Gaia Date 2015-03-05 17:19:31 Gecko Revision c77dc549894cf6956ca49cfb22228d5e4d2f9a2f Gecko Version 32.0 Device Name jrdhz72_w_ff Firmware(Release) 4.4.2 Firmware(Incremental) 1425589555 Firmware Date Fri Mar 6 05:06:19 CST 2015 Dolphin 2.1s (512mb) build: 2.1s 512 Gaia-Rev 5be7b6c19483e4d5c941a3b97dc08a3b5d7202dd Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/e42dc5e5f729 Build-ID 20150305002323 Version 34.0 Device-Name scx15_sp7715ea FW-Release 4.4.2 FW-Incremental 122 FW-Date Thu Feb 5 12:42:58 CST 2015 N5_2.2 build: Build ID 20150305002528 Gaia Revision 89af288bad6751248ff84504fa898206fee127fe Gaia Date 2015-03-04 18:00:05 Gecko Revision https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/6d8d294aa8f3 Gecko Version 37.0 Device Name hammerhead Firmware(Release) 5.0 Firmware(Incremental) eng.cltbld.20150305.041802 Firmware Date Thu Mar 5 04:18:17 EST 2015 Bootloader HHZ12d
Flags: needinfo?(fan.luo) → needinfo?(sarsenyev)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
Keywords: qawanted
(In reply to Shine from comment #36) > Created attachment 8573668 [details] > Video > > Hi Reporter, > This problem cannot be repro on latest build of Woodduck 2.0, Dolphin > 2.1S(512m) and 2.2 Nexus 5, Could you help to confirm whether the STR in my > video is correct? Thanks! > See attachment: Video.MP4 > Fail rate: 0/20 > FYI, I was able to reproduce it on my flame using your STR, but in my case I used 10 - 15 second videos I took with the flame device. Changing sliders back and forth will eventually cause the app to crash, with about 50% of the repro rate.
Followed up with mvines in https://bugzilla.mozilla.org/show_bug.cgi?id=1101826
Flags: needinfo?(bbajaj)
See Also: → 1138671
Component: Video/Audio → Vendcom
Product: Core → Firefox OS
Whiteboard: [2.1-exploratory-3] → [2.1-exploratory-3][POVB]
according to comment 36 and 38, this crash case is chip specific. -- Keven
Whiteboard: [2.1-exploratory-3][POVB] → [2.1-exploratory-3][POVB], b2g-crash
There is nothing I can do more.
Assignee: sotaro.ikeda.g → nobody
de-nom it as vendor has no plan to fix it.
blocking-b2g: 2.0+ → ---
John was able to reproduce this on 2.2 but not 3.0. Adding qawanted to double check the reproducibility on 3.0.
Flags: needinfo?(sarsenyev)
Keywords: qawanted
I was able to reproduce this bug as well. Comment 40 mean that this bug will not be fixed at all or for a particular release? If not at all, should it remain open and new?
Flags: needinfo?(sotaro.ikeda.g)
This bug is actually Bug 1101826. This bug should be dup of it. And the reason why it is not fixed is not technical reason.
Flags: needinfo?(sotaro.ikeda.g)
Removing qawanted since there are no plans to fix this and duping to Bug 1101826 per Sotaro's comment.
Status: NEW → RESOLVED
Closed: 10 years ago
Keywords: qawanted
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: