1009922 - [Open C] crash in __pthread_cond_pulse

Status: RESOLVED WONTFIX

(Core :: WebRTC, defect)

Description

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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

Comment 1

[Jason Smith [:jsmith]]

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

Comment 2

[Jason Smith [:jsmith]]

Rachel - How did you reproduce this?

Comment 3

[Rachel Pribble [:rpribble]]

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

Comment 4

[Jason Smith [:jsmith]]

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

Comment 5

[Rachel Pribble [:rpribble]]

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.

Comment 6

[Joshua Mitchell (Inactive)]

QAWanted to check if this repros in 1.4

Comment 7

[Cody Roesch [:croesch]]

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.

Comment 8

[Cody Roesch [:croesch]]

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

Comment 9

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

jsmith, please see comment 7

Comment 10

[Jason Smith [:jsmith]]

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

Comment 11

[Cody Roesch [:croesch]]

(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.

Comment 12

[Cody Roesch [:croesch]]

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.

Comment 13

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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

Comment 14

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 15

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 16

[Gian-Carlo Pascutto [:gcp]]

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.

Comment 17

[Gian-Carlo Pascutto [:gcp]]

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

Comment 18

[Joshua Mitchell (Inactive)]

removing outdated qa-wanted tag

Comment 19

[Jason Smith [:jsmith]]

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?

Comment 20

[Joshua Mitchell (Inactive)]

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

Comment 21

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.