This bug was filed from the Socorro interface and is report bp-5a8bef14-1efe-43d1-9e86-6ee562140512. ============================================================= Crashing Thread Frame Module Signature Source 0 libc.so __pthread_cond_pulse /home/duanxiaodong/8x10_AP_20140430/boot/bionic/libc/bionic/pthread.c 1 libmedia.so android::AudioRecord::stop() /home/duanxiaodong/8x10_AP_20140430/boot/frameworks/native/include/utils/Condition.h 2 libwilhelm.so android_audioRecorder_destroy(CAudioRecorder_struct*) /builds/slave/b2g_m-cen_flame_ntly-000000000/build/frameworks/wilhelm/src/android/AudioRecorder_to_android.cpp 3 libwilhelm.so IObject_Destroy(SLObjectItf_ const* const*) /builds/slave/b2g_m-cen_flame_ntly-000000000/build/frameworks/wilhelm/src/itf/IObject.c 4 libxul.so webrtc::OpenSlesInput::DestroyAudioRecorder() media/webrtc/trunk/webrtc/modules/audio_device/android/opensles_input.cc 5 libxul.so webrtc::OpenSlesInput::StopRecording() media/webrtc/trunk/webrtc/modules/audio_device/android/opensles_input.cc 6 libxul.so webrtc::AudioDeviceModuleImpl::StopRecording() media/webrtc/trunk/webrtc/modules/audio_device/audio_device_impl.cc 7 libxul.so webrtc::VoEBaseImpl::StopSend() media/webrtc/trunk/webrtc/voice_engine/voe_base_impl.cc 8 libxul.so webrtc::VoEBaseImpl::StopSend(int) media/webrtc/trunk/webrtc/voice_engine/voe_base_impl.cc 9 libxul.so mozilla::MediaEngineWebRTCAudioSource::Stop(mozilla::SourceMediaStream*, int) content/media/webrtc/MediaEngineWebRTCAudio.cpp 10 libxul.so mozilla::MediaOperationRunnable::Run() dom/media/MediaManager.h 11 libxul.so nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 12 libxul.so NS_ProcessNextEvent(nsIThread*, bool) xpcom/glue/nsThreadUtils.cpp 13 libxul.so mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 14 libxul.so MessageLoop::RunInternal() ipc/chromium/src/base/message_loop.cc 15 libxul.so MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 16 libxul.so nsThread::ThreadFunc(void*) xpcom/threads/nsThread.cpp 17 libnss3.so _pt_root nsprpub/pr/src/pthreads/ptthread.c 18 libc.so __thread_entry /home/duanxiaodong/8x10_AP_20140430/boot/bionic/libc/bionic/pthread_create.cpp 19 libc.so pthread_create /home/duanxiaodong/8x10_AP_20140430/boot/bionic/libc/bionic/pthread_create.cpp More crashes : https://crash-stats.mozilla.com/report/list?product=B2G&signature=__pthread_cond_pulse#tab-reports

Not sure if this is vendor-specific - let me send this over to the WebRTC component to get someone to double check.

Rachel - How did you reproduce this?

It occurred a lot in our Flame v2.0 test run during Media Recording API test cases. Repro steps: 1) Install the app from http://mozilla.github.io/qa-testcase-data/webapi/mediarecorder/index.html (packaged app used in test) 2) Select microphone > tap setup > grant permissions 3) Observe app crash v2.0 Environmental Variables: Device: Flame v2.0 MOZ ril BuildID: 20140609040203 Gaia: 12af93123c5db55212d51fe235d39f21209a1eaa Gecko: 9305a8ec77fe Version: 32.0a1 Firmware Version: v10G-2

Using the STR described in comment 3, can we determine a reproduction rate?

Repro rate: 10/10 A teammate and myself have seen a 100% crash rate when using these specific repro steps in the installed media app.

QAWanted to check if this repros in 1.4

After running this test on Flame 2.1, Flame 2.0, Flame 1.4 and Flame base v121, I've been able to crash this process but not without some red flags. From Comment 3, Running the Browser version by itself or the Packaged app by itself, I'm unable to produce a crash and the app runs smoothly. However if 1 of the processes is already recording (Browser or Packaged) then the other version starts recording as well, a crash occurs immediately. 1. Is there another step/option that was set that I'm not aware of based on the info above? 2. Is it possible that what I've described (accidentally running multiple versions at the same time) could be what occurred? 3. If this is the case than is it valid? Before I do a branch checks, it would be nice to have some more clarity on these questions.

Here are the variables tested on Environmental Variables: Device: Flame Master Build ID: 20140623053744 Gaia: bd5065ced020014df5fd45259fba1ac32d65673b Gecko: 335b6610fe0c Version: 33.0a1 (Master) Firmware Version: v122 ------------------------------------- Environmental Variables: Device: Flame 2.0 Build ID: 20140623051745 Gaia: 84ca0fe0a86d039f6d99cb562f52ef55045dee1d Gecko: cef223bae66b Version: 32.0a2 (2.0) Firmware Version: v122 --------------------------------------- Environmental Variables: Device: Flame 1.4 Build ID: 20140623000201 Gaia: 3419a1f68aaf64a0688685bce42d4173b6125597 Gecko: 34ecc9af3560 Version: 30.0 (1.4) Firmware Version: v122 ---------------------------------------- Environmental Variables: Device: Flame 1.3 Build ID: 20140610200025 Gaia: e106a3f4a14eb8d4e10348efac7ae6dea2c24657 Gecko: b637b0677e15318dcce703f0358b397e09b018af Version: 28.0 (1.3) Firmware Version: v121-2

jsmith, please see comment 7

I can't really follow the questions mentioned here. Can you rephrase?

(In reply to Jason Smith [:jsmith] from comment #10) > I can't really follow the questions mentioned here. Can you rephrase? Basically I was asking if I may have not had all the information I needed to reproduce this crash in the manner described in Comment 3. The only crash I could reproduce was when I ran both the Browser version of the app and the Packaged version of the app at the same time. I asked if it's possible that this situation may have occured. This is the website Rpibble listed that the crash occurred on. http://mozilla.github.io/qa-testcase-data/webapi/mediarecorder/index.html I was also wrong to NI Naoki as I was instructed to do. Apologies.

As far as Psiphantong's comment about being able to repro this crash, he used a different website http://mozilla.github.io/qa-testcase-data/webapi/webrtc/multigumaudiocontent.html I asked him to repro this bug for me today with the same setup he used before and he has been unable to produce a crash. I've had multiple people try to reproduce his crash today and noone has been able to.

to note, this crashing has been occuring at least since build 20140604040204.

Though perhaps this was obvious, this is a b2g crash, not Android

This may be related to trying to use OpenSL from multiple processes (B2G apps) at once - gcp? It seems deep inside the OpenSL/Android media code

There's no reason why that shouldn't be be possible, save for Android OpenSLES bugs. We've hit some similar ones: bug 1020227. This needs to be debugged.

FYI https://code.google.com/p/android/issues/detail?id=70904

removing outdated qa-wanted tag

Josh - I'm not sure if the qawanted request here was addressed clearly, as I can't follow if we determined this is a regression or not. Can you get that information here?

To my understanding, Comment 16 and comment 15 verify that " OpenSL from multiple processes (B2G apps) at once " SHOULD be a valid test which in turn verifies the information / branch checks from comment 8 indicating that this is NOT a regression

Closing because no crash reported since 12 weeks.