This bug was filed from the Socorro interface and is report bp-e2636694-e520-4f92-a08e-2063b2150914. ============================================================= If the user keeps tapping next in the FTU at a rapid rate, they will be notified that the "FTU" has crashed once they reach the homescreen. Repro Steps: 1) Update a Aries to 20150914130903 2) Quickly tap through the FTE as fast possible to reach the homescreen. 3) Observe what occurs after reaching the homescreen. Actual: The user will be notified that the FTU has crashed. Expected: The FTU should not crash regardless of how fast the user taps through the FTU. Environmental Variables: Device: Aries 2.5 Build ID: 20150914130903 Gaia: f37e8f732e0af961b43e912629c84c9e2ceda55d Gecko: fba4b0cd3823975949765acc0b16b964d1712b75 Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 43.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0 Repro frequency: 5/5 100% See attached: logcat,video Frame Module Signature Source 0 libc.so strlen 1 libc.so __vfprintf /home/worker/workspace/B2G/bionic/libc/include/string.h:217 2 libc.so vsnprintf /home/worker/workspace/B2G/bionic/libc/stdio/vsnprintf.c:61 3 liblog.so __android_log_print /home/worker/workspace/B2G/bionic/libc/include/stdio.h:461 4 libxul.so mozilla::GonkVideoDecoderManager::codecReserved() dom/media/platforms/gonk/GonkVideoDecoderManager.cpp 5 libxul.so nsRunnableMethodImpl<nsresult (mozilla::MediaDataDecoder::*)(), true>::Run() /home/worker/objdir-gecko/objdir/dist/include/nsThreadUtils.h:661 6 libxul.so mozilla::TaskQueue::Runner::Run() xpcom/threads/TaskQueue.cpp 7 libxul.so nsThreadPool::Run() xpcom/threads/nsThreadPool.cpp 8 libxul.so nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 9 libxul.so NS_ProcessNextEvent(nsIThread*, bool) xpcom/glue/nsThreadUtils.cpp 10 libxul.so mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 11 libxul.so MessageLoop::RunInternal() ipc/chromium/src/base/message_loop.cc 12 libxul.so MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 13 libxul.so nsThread::ThreadFunc(void*) xpcom/threads/nsThread.cpp 14 libnss3.so _pt_root nsprpub/pr/src/pthreads/ptthread.c 15 libc.so __thread_entry /home/worker/workspace/B2G/bionic/libc/bionic/pthread_create.cpp:105 16 libc.so pthread_create /home/worker/workspace/B2G/bionic/libc/bionic/pthread_create.cpp:224 17 @0xaf660cbe

This issue also occurs on the Flame 2.5 The "FTU" will crash if the user goes through the FTU at a rapid rate to reach the homescreen. Device: Flame 2.5 (Full Flash)(KK)(319mb) BuildID: 20150914030233 Gaia: 4d9b996be4b1935651057d0651461c1a36d98a18 Gecko: 9ed17db42e3e46f1c712e4dffd62d54e915e0fac Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd Version: 43.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0 ------------------------------ This issue does not occur on Flame 2.2 The FTU does not crash when going through the FTU at a rapid rate. Device: Flame 2.2 (Full Flash)(KK)(319mb) BuildID: 20150914032507 Gaia: 7a427e0f8aa6c185a9e22358006b97c19435ca4a Gecko: 0d9c46d01861 Gonk: bd9cb3af2a0354577a6903917bc826489050b40d Version: 37.0 (2.2) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

B2G Inbound Regression Window Last Working Device: Flame 2.5 Environmental Variables BuildID: 20150909044138 Gaia: 47459eead04385e22f967012b824f5abdddcfb7c Gecko: 834376f2e95eeb0e96b8eca6c251475562b5da53 Version: 43.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0 First Broken Device: Flame 2.5 BuildID: 20150909045138 Gaia: 47459eead04385e22f967012b824f5abdddcfb7c Gecko: a3fe551ea06bd43a99cb0fc32cd876450d64e17d Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67 Version: 43.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0 Last Working gaia / First Broken gecko - This issue DOES occur. Gaia: 47459eead04385e22f967012b824f5abdddcfb7c Gecko: a3fe551ea06bd43a99cb0fc32cd876450d64e17d Last Working gecko / First Broken gaia - This issue does NOT occur. Gecko: 834376f2e95eeb0e96b8eca6c251475562b5da53 Gaia: 47459eead04385e22f967012b824f5abdddcfb7c B2G Inbound Pushlog: http://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=834376f2e95eeb0e96b8eca6c251475562b5da53&tochange=a3fe551ea06bd43a99cb0fc32cd876450d64e17d This issue is caused by Bug 1201969

Alastor this issue seems to have been caused by the changes for Bug 1201969. Can you please take a look?

Hi, I can't reproduce this issue at following buildID - 20150915141648. Could you help me to check whether this issue have already been solved? Thanks!

I am still able to reproduce this issue on today's Flame and Aries builds. Note: This issue seems to reproduce more often if you keep pressing where the Next button would be after the tutorial ends. Actual Results: A crash signature is generated when rapidly progressing past the FTU. Environmental Variables: Device: Aries 2.5 BuildID: 20150916015546 Gaia: 994ff1537c2d7ca4d1658806c50f3ceba1053f9b Gecko: 3e8dde8f8c174cce2c0b65c951808f88e35d1875 Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 43.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0 Environmental Variables: Device: Flame 2.5 BuildID: 20150916030229 Gaia: 994ff1537c2d7ca4d1658806c50f3ceba1053f9b Gecko: 3e8dde8f8c174cce2c0b65c951808f88e35d1875 Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd Version: 43.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Related: bug 1192978. We should fix the underlying regression, but the front-end code could also be more resilient.

I still can't reproduce this issue in following testing environments. Is any possible the firmware issue? Or you have any other preprocess? Environmental Variables: [Flame 2.5 Kk] Gaia-Rev 01cf74daf8e1c1fbc945dd61ff0b2524f4b06b8e Gecko-Rev 262451:c69e31de9aec Build-ID 20150916181705 Version 43.0a1 Device-Name flame FW-Release 4.4.2 FW-Incremental 75 FW-Date Tue Jan 6 12:24:47 CST 2015 Bootloader L1TC100118D0 [Aries 2.5KK] Gaia-Rev 250c2dfa9cd6eb6ce5b7162e5f53a3b6a33c3aef Gecko-Rev 3a3b80f18175a053d86c9adbe74909dcaa9c184c Build-ID 20150916104746 Version 43.0a1 Device-Name aries FW-Release 4.4.2 FW-Incremental eng.worker.20150616.234403 FW-Date Tue Jun 16 23:44:13 UTC 2015 Bootloader s1

Regression. Crash occurs but with unusual steps. P2 priority

I can reproduce this issue now, investigating.

I found that the |mMimeType| in GonkVideoDecoderManager.cpp have already been deleted, the address of its content is 0x5a5a5a5a. This crash might be caused by loading video multiple time when user press next button rapidly (bug 1192978). But, we still need to find why this behavior would cause crash.

Here is the crash log. When we call GonkVideoDecoderManager::codecReserved, we found that the mDecoder are 0x5a5a5a5a. This crash sometime can't be reproduced. If the codecReserved is called before the GonkMediaDataDecoder dtor, the crash doesn't happen.

Blake will help this issue.

Alfredo, Would you be available to help Alastor check it?

VideoResourceListener's lifetime is longer than GonkVideoDecoderManager and it causes this crash. [1] https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/gonk/GonkVideoDecoderManager.cpp#68

VideoResourceListener lifecycle could be longer than GonkVideoDecoderManager, so we need to keeps a reference to VideoResourceListener when a codec reserved runnable is in reader task queue.

Comment on attachment 8667757 [details] [diff] [review] release_listener_at_reader_thread Review of attachment 8667757 [details] [diff] [review]: ----------------------------------------------------------------- not sure I fully follow not knowing enough about how CodecManager works. but LGTM ::: dom/media/platforms/gonk/GonkVideoDecoderManager.cpp @@ +566,5 @@ > { > + // This class holds VideoResourceListener reference to prevent it's destroyed. > + class CodecListenerHolder : public nsRunnable { > + public: > + CodecListenerHolder(VideoResourceListener* aListener) use initializers. : mVideoListener(aListener) or something

This issue is verified fixed on the latest Flame and Spark 2.5 master builds. The FTU does not crash when going through the FTU at a rapid rate. Environmental Variables: Device: Aries 2.5 BuildID: 20151006110922 Gaia: 60cdaa3d3424db3432dc903e7f9c6c8fa099c06d Gecko: 89732fcdb0baca70e8b7a25a2725117113f0db80 Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd Version: 44.0a1 (2.5) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0 Environmental Variables: Device: Flame 2.5 BuildID: 20151006030203 Gaia: 60cdaa3d3424db3432dc903e7f9c6c8fa099c06d Gecko: 3edc8d4a1e198314f5d7ebd2967b85842beef602 Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd Version: 44.0a1 (2.5) Firmware Version: v18D User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0