Closed Bug 1009922 Opened 8 years ago Closed 4 years ago

[Open C] crash in __pthread_cond_pulse

Categories

(Core :: WebRTC, defect)

ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

()

RESOLVED WONTFIX
tracking-b2g backlog
Tracking Status
b2g-v1.3 --- affected
b2g-v1.4 --- affected
b2g-v2.0 --- affected
b2g-v2.1 --- affected
backlog parking-lot

People

(Reporter: nhirata, Unassigned)

References

()

Details

(Keywords: crash, reproducible, Whiteboard: [b2g-crash], permafail)

Crash Data

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
Whiteboard: [b2g-crash]
Whiteboard: [b2g-crash] → [b2g-crash][2.0-flame-test-run-1]
Not sure if this is vendor-specific - let me send this over to the WebRTC component to get someone to double check.
Component: Vendcom → WebRTC
Product: Firefox OS → Core
Version: unspecified → Trunk
Rachel - How did you reproduce this?
Flags: needinfo?(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
Flags: needinfo?(rpribble)
Using the STR described in comment 3, can we determine a reproduction rate?
blocking-b2g: --- → backlog
Keywords: qawanted
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.
Keywords: qawanted
Flags: needinfo?(jmitchell)
Whiteboard: [b2g-crash][2.0-flame-test-run-1] → [b2g-crash][2.0-flame-test-run-1], [QAnalyst-Triage?]
QAWanted to check if this repros in 1.4
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Whiteboard: [b2g-crash][2.0-flame-test-run-1], [QAnalyst-Triage?] → [b2g-crash][2.0-flame-test-run-1]
QA Whiteboard: [QAnalyst-Triage?]
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Whiteboard: [b2g-crash][2.0-flame-test-run-1] → [b2g-crash],[2.0-flame-test-run-1],[2.0-flame-test-run-2]
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
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.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(nhirata.bugzilla)
QA Contact: croesch
Flags: needinfo?(jmitchell)
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
QA Whiteboard: [QAnalyst-Triage?]
jsmith, please see comment 7
Flags: needinfo?(nhirata.bugzilla) → needinfo?(jsmith)
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Whiteboard: [b2g-crash],[2.0-flame-test-run-1],[2.0-flame-test-run-2] → permafail
Whiteboard: permafail → [b2g-crash],[2.0-flame-test-run-1],[2.0-flame-test-run-2]
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: reproducible
I can't really follow the questions mentioned here. Can you rephrase?
Flags: needinfo?(jsmith) → needinfo?(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.
Flags: needinfo?(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.
to note, this crashing has been occuring at least since build 20140604040204.
Though perhaps this was obvious, this is a b2g crash, not Android
OS: Android → Gonk (Firefox OS)
Hardware: All → ARM
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
Flags: needinfo?(gpascutto)
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.
Flags: needinfo?(gpascutto)
Flags: needinfo?(jmitchell)
Blocks: 1004761
removing outdated qa-wanted tag
Keywords: qawanted
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?
Flags: needinfo?(jmitchell)
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
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dharris)
Whiteboard: [b2g-crash],[2.0-flame-test-run-1],[2.0-flame-test-run-2] → [b2g-crash], permafail
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
blocking-b2g: backlog → ---
backlog: --- → parking-lot
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.