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

RESOLVED DUPLICATE of bug 1101826

Status

--
critical
RESOLVED DUPLICATE of bug 1101826
4 years ago
4 years ago

People

(Reporter: sarsenyev, Unassigned)

Tracking

({crash})

unspecified
ARM
Gonk (Firefox OS)
crash
Dependency tree / graph

Firefox Tracking Flags

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

Details

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

Attachments

(4 attachments)

(Reporter)

Description

4 years ago
Created attachment 8523160 [details]
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
(Reporter)

Comment 1

4 years ago
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)
(Reporter)

Updated

4 years ago
Keywords: regression
(Reporter)

Updated

4 years ago
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)

Comment 4

4 years ago
Hi Vincent:
 Please help check if any clue on this bug!!

Thanks!!
Shawn
Flags: needinfo?(vliu)

Comment 5

4 years ago
[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?

Comment 6

4 years ago
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.
(Reporter)

Comment 8

4 years ago
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

Comment 9

4 years ago
(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
(Reporter)

Comment 10

4 years ago
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

Comment 11

4 years ago
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)

Comment 12

4 years ago
Created attachment 8525107 [details]
big_buck_bunny_trailer_480p_baseline.mp4

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)

Comment 13

4 years ago
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.

Updated

4 years ago
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.

Updated

4 years ago
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)

Updated

4 years ago
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.

Comment 25

4 years ago
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.
Created attachment 8555399 [details] [diff] [review]
temporary patch - 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)

Comment 33

4 years ago
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)
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

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)

Updated

4 years ago
See Also: → bug 1138671

Updated

4 years ago
Component: Video/Audio → Vendcom
Product: Core → Firefox OS
Whiteboard: [2.1-exploratory-3] → [2.1-exploratory-3][POVB]

Comment 39

4 years ago
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
Last Resolved: 4 years ago
Keywords: qawanted
Resolution: --- → DUPLICATE
Duplicate of bug: 1101826
You need to log in before you can comment on or make changes to this bug.