Closed Bug 878033 Opened 11 years ago Closed 11 years ago

Loading Youtube app hangs

Categories

(Firefox OS Graveyard :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: roc, Unassigned)

Details

(Keywords: hang)

While trying to reproduce bug 877461 I got into a state where we hung while trying to load a new Youtube page. We seem to have hung cleaning up OmxDecoder on the main thread: Thread 1 (Thread 2883.2883): #0 __futex_syscall3 () at bionic/libc/arch-arm/bionic/atomics_arm.S:182 ---Type <return> to continue, or q <return> to quit--- #1 0x4010855c in __pthread_cond_timedwait_relative (cond=0x467a5c84, mutex=0x467a5c80, reltime=0x0) at bionic/libc/bionic/pthread.c:1477 #2 0x40108610 in __pthread_cond_timedwait (cond=0x467a5c84, mutex=0x467a5c80, abstime=0x0, clock=0) at bionic/libc/bionic/pthread.c:1500 #3 0x42110230 in android::Condition::wait (this=0x467a5bd0) at frameworks/base/include/utils/threads.h:455 #4 android::OMXCodec::stop (this=0x467a5bd0) at frameworks/base/media/libstagefright/OMXCodec.cpp:4909 #5 0x40b4feda in ~OmxDecoder (this=0x44cee5e0, __in_chrg=<value optimized out>) at /home/roc/mozilla-b2g18v1/content/media/omx/OmxDecoder.cpp:172 #6 0x40b4ff7e in ~OmxDecoder (this=0x467a5c84, __in_chrg=<value optimized out>) at /home/roc/mozilla-b2g18v1/content/media/omx/OmxDecoder.cpp:183 #7 0x4225ff12 in android::RefBase::decStrong (this=0x44cee5e0, id=0x442e87c4) at frameworks/base/libs/utils/RefBase.cpp:359 #8 0x40b4efcc in android::sp<android::OmxDecoder>::clear (this=0x442e8700) at /home/roc/B2G/frameworks/base/include/utils/StrongPointer.h:200 #9 nsMediaOmxReader::ResetDecode (this=0x442e8700) at /home/roc/mozilla-b2g18v1/content/media/omx/nsMediaOmxReader.cpp:109 #10 0x40b4f186 in ~nsMediaOmxReader (this=0x467a5c84, __in_chrg=<value optimized out>) at /home/roc/mozilla-b2g18v1/content/media/omx/nsMediaOmxReader.cpp:32 #11 0x40b4f1b6 in ~nsMediaOmxReader (this=0x467a5c84, __in_chrg=<value optimized out>) at /home/roc/mozilla-b2g18v1/content/media/omx/nsMediaOmxReader.cpp:33 #12 0x40badb18 in nsAutoPtr<nsBuiltinDecoderReader>::assign (this=0x467a4804, rhs=<value optimized out>) at ../../dist/include/nsAutoPtr.h:38 #13 nsAutoPtr<nsBuiltinDecoderReader>::operator= (this=0x467a4804, rhs=<value optimized out>) at ../../dist/include/nsAutoPtr.h:101 #14 0x40badbe0 in ~nsBuiltinDecoderStateMachine (this=0x467a47a0, __in_chrg=<value optimized out>) at /home/roc/mozilla-b2g18v1/content/media/nsBuiltinDecoderStateMachine.cpp:452 #15 0x40b4e6aa in ~MediaOmxStateMachine (this=0x467a5c84, __in_chrg=<value optimized out>) at /home/roc/mozilla-b2g18v1/content/media/omx/MediaOmxStateMachine.h:8 #16 0x40b4e6be in ~MediaOmxStateMachine (this=0x467a5c84, __in_chrg=<value optimized out>) at /home/roc/mozilla-b2g18v1/content/media/omx/MediaOmxStateMachine.h:8 #17 0x41133918 in nsRunnable::Release (this=0x467a47a0) at /home/roc/mozilla-b2g18v1/obj-gonk-debug/xpcom/build/nsThreadUtils.cpp:30 #18 0x403e4ce6 in nsCOMPtr<nsIRDFDelegateFactory>::assign_assuming_AddRef ( this=0x44222450, newPtr=<value optimized out>) at ../../dist/include/nsCOMPtr.h:477 #19 0x40badada in nsCOMPtr<nsBuiltinDecoderStateMachine>::assign_with_AddRef ( this=<value optimized out>) at ../../dist/include/nsCOMPtr.h:1136 #20 nsCOMPtr<nsBuiltinDecoderStateMachine>::operator= ( ---Type <return> to continue, or q <return> to quit--- this=<value optimized out>) at ../../dist/include/nsCOMPtr.h:622 #21 nsDecoderDisposeEvent::Run (this=<value optimized out>) at /home/roc/mozilla-b2g18v1/content/media/nsBuiltinDecoderStateMachine.cpp:1977 #22 0x4116c552 in nsThread::ProcessNextEvent (this=0x42407240, mayWait=<value optimized out>, result=0xbe8f6dd7) at /home/roc/mozilla-b2g18v1/xpcom/threads/nsThread.cpp:620 Chris, could this be related to the Android libstagefright cleanup threading issues you were working on a while ago?
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #0) > > Chris, could this be related to the Android libstagefright cleanup threading > issues you were working on a while ago? No, this looks like there's an outstanding video buffer and it's blocking for it to be freed. Do you have any other patches applied or landed recently that might effect that?
See bug 791912 for what caused similar hangs and crashes in the past.
I saw this twice, although the hangs I saw were not permanent - if you waited about 3 - 5 seconds, YouTube would no longer be hung.
Keywords: hang
Somebody needs to check to see if this reproduces on 1.1 with videos from https://m.youtube.com/?tsp=1&player=html5&monetize=1.
Keywords: qawanted
It seems that deallocate OmxDecoder on main thread is bad. Similar thing as in Bug 878183 comment #5 could happen.
(In reply to Sotaro Ikeda [:sotaro] from comment #5) > It seems that deallocate OmxDecoder on main thread is bad. Similar thing as > in Bug 878183 comment #5 could happen. I am changing it in Bug 870071. In Bug 870071, OmxDecoder is deallocated in state machine's thread.
(In reply to Sotaro Ikeda [:sotaro] from comment #6) > (In reply to Sotaro Ikeda [:sotaro] from comment #5) > > It seems that deallocate OmxDecoder on main thread is bad. Similar thing as > > in Bug 878183 comment #5 could happen. > > I am changing it in Bug 870071. In Bug 870071, OmxDecoder is deallocated in > state machine's thread. Bug 870071 is marked as a dupe of a bug that seems to have been resolved fixed with a gaia patch. Is that the correct bug number?
(In reply to Chris Double (:doublec) from comment #7) > > Bug 870071 is marked as a dupe of a bug that seems to have been resolved > fixed with a gaia patch. Is that the correct bug number? Sorry, Bug 871485 is the correct bug number.
I was not able to reproduce this bug on v1.1 Unagi build Build ID: 20130603070207 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/4785b1353fd7 Gaia: 4de4354e3a99f151a834743c7b03a041ac8db12f Version 18.0 Youtube videos from https://m.youtube.com/?tsp=1&player=html5&monetize=1 do not hang and continue to play with no interruption.
Keywords: qawanted
No longer blocks: 877024
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
It seems like roc's environment is v1.01 unagi. If it is correct, it is dupe of Bug 878981.
(In reply to Sotaro Ikeda [:sotaro] from comment #10) > It seems like roc's environment is v1.01 unagi. If it is correct, it is dupe > of Bug 878981. Bug 878981 is a bug for v1.1. But same problem could be happen also in v1.0.1.
I have to say that qcom does not support v1.1 for unagi and inari(ics_chocolate) now.
You need to log in before you can comment on or make changes to this bug.