Closed Bug 1291745 Opened 9 years ago Closed 9 years ago

hang in MediaStreamGraphImpl::RunInStableState

Categories

(Core :: Audio/Video: cubeb, defect, P1)

x86
macOS
defect

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
firefox51 --- affected

People

(Reporter: asqueella, Unassigned)

References

Details

(Keywords: hang)

Attachments

(1 file)

Attached file Sample of Nightly.txt
Not sure if this report is actionable, logging in case there's something useful in the attached stack trace; this is the only time I've seen a hang like this. I had Nightly running for a while, using my main profile (many tabs, including GMail and web.telegram.org). After resuming the Macbook from sleep and using other applications for a while, I noticed it was hung, consuming ~0.7 CPU. The watchdog didn't kill it after a few minutes. I sampled the process using the Activity monitor and noticed that the main thread was stuck in: 2027 XPCJSRuntime::AfterProcessTask(unsigned int) 2027 mozilla::CycleCollectedJSRuntime::ProcessStableStateQueue() 2027 mozilla::(anonymous namespace)::MediaStreamGraphStableStateRunnable::Run() 2027 mozilla::MediaStreamGraphImpl::RunInStableState(bool) 2027 PR_Lock 2027 _pthread_mutex_lock 2027 __psynch_mutexwait There were a few "Media playback" threads with the following trace: 2027 mozilla::MediaDecoderStateMachine::StartMediaSink() 2027 mozilla::media::VideoSink::Start(long long, mozilla::MediaInfo const&) 2027 mozilla::media::AudioSinkWrapper::Start(long long, mozilla::MediaInfo const&) 2027 mozilla::media::DecodedAudioDataSink::Init(mozilla::media::MediaSink::PlaybackParams const&) 2027 mozilla::media::DecodedAudioDataSink::InitializeAudioStream(....) 2027 mozilla::AudioStream::Init(unsigned int, unsigned int, mozilla::dom::AudioChannel) 2027 mozilla::AudioStream::OpenCubeb(cubeb_stream_params&, mozilla::TimeStamp, bool) 2027 audiounit_stream_init(cubeb*, .......) 2027 audiounit_create_unit(....) 2027 _AT_AudioComponentInstanceNew 2027 APComponent::NewInstance(ComponentInstanceRecord*&) 2027 ComponentBase::AP_Open(void*, ComponentInstanceRecord*) 2027 _pthread_mutex_lock 2027 __psynch_mutexwait And one stuck in: 2027 mozilla::MediaDecoderStateMachine::StartMediaSink() 2027 mozilla::media::VideoSink::Start(long long, mozilla::MediaInfo const&) 2027 mozilla::media::AudioSinkWrapper::Start(long long, mozilla::MediaInfo const&) 2027 mozilla::media::DecodedAudioDataSink::Init(mozilla::media::MediaSink::PlaybackParams const&) 2027 mozilla::media::DecodedAudioDataSink::InitializeAudioStream(....) 2027 mozilla::AudioStream::Init(unsigned int, unsigned int, mozilla::dom::AudioChannel) 2027 mozilla::AudioStream::OpenCubeb(cubeb_stream_params&, mozilla::TimeStamp, bool) 2027 audiounit_stream_init(cubeb*, .....) 2027 audiounit_create_unit(.....) 2027 _AT_AudioComponentInstanceNew 2027 APComponent::NewInstance(ComponentInstanceRecord*&) 2027 ComponentBase::AP_Open(void*, ComponentInstanceRecord*) 2027 APFactory<AUOutputLookup, AUHAL>::Construct(void*, ComponentInstanceRecord*) 2027 AUHAL::AUHAL(ComponentInstanceRecord*, unsigned int, bool) 2027 AUHAL::SelectDevice(unsigned int) 2027 AudioDeviceCreateIOProcID 2027 HALDevice::CreateIOProcID(....) 2027 HALPlugIn::DeviceCreateIOProcID(....) 2027 HAL_HardwarePlugIn_DeviceCreateIOProcID(....) 2027 HALC_ShellDevice::CreateIOProcID(....) 2027 HALC_ProxyIOContext::CreateIOProcID(....) 2027 HALB_Mutex::Lock() 2027 _pthread_mutex_lock 2027 __psynch_mutexwait Unfortunately Nightly auto-updated after restarting, so I don't know the exact version that was running (a build from end of July I guess). I also have a system-wide spindump (not attaching here).
Component: Audio/Video → Audio/Video: Playback
Component: Audio/Video: Playback → Audio/Video: cubeb
Stream hung in 2027 audiounit_stream_init(cubeb*, .....)... Mac OS issue? Bug in cubeb?
Rank: 17
Priority: -- → P1
In both thread stucks I see the hung inside framework method AudioComponentInstanceNew() which is called by cubeb_stream_init(). In general OSX documentation sucks and it does not mention anything about the multithreading policy of the method but we use it in the same way that is used by other projects or code samples. In addition I created and stand alone example that calls the cubeb_stream_init() method in many (too many) parallel threads and I do not get any hung in my machine. Thus I believe cubeb is not the root cause of that issue.
Looks like some sort of deadlock inside the AP_Open code (inside the Mac OS). Presumably this is somehow related to waking it up from sleep, but that isn't certain. At this point, I don't think there's anything actionable here without more data or the ability to reproduce it. Most likely it's a bug in the mac OS code, perhaps related to sleep, perhaps to some other process having locked some resource or having a bug coming out of sleep. Nickolay: thanks for a very detailed bug report! let us know if it happens again and we can reopen
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
See Also: → 1317234
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: