1749281 - Crash in [@ mozilla::AudioInputProcessing::PacketizeAndProcess]

Status: RESOLVED FIXED

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

Description

[Gabriele Svelto [:gsvelto] (PTO)]

Crash report: https://crash-stats.mozilla.org/report/index/690f286a-d1b6-4172-be0d-459a60220108

Reason: EXCEPTION_INT_DIVIDE_BY_ZERO

Top 10 frames of crashing thread:

0 xul.dll mozilla::AudioInputProcessing::PacketizeAndProcess dom/media/webrtc/MediaEngineWebRTCAudio.cpp:871
1 xul.dll mozilla::AudioInputProcessing::EnsureAudioProcessing dom/media/webrtc/MediaEngineWebRTCAudio.cpp:1132
2 xul.dll mozilla::StartStopMessage::Run dom/media/webrtc/MediaEngineWebRTCAudio.cpp:386
3 xul.dll mozilla::MediaTrackGraphImpl::OneIterationImpl dom/media/MediaTrackGraph.cpp:1562
4 xul.dll mozilla::GraphRunner::Run dom/media/GraphRunner.cpp:139
5 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1189
6 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:300
7 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:324
8 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:306
9 xul.dll static nsThread::ThreadFunc xpcom/threads/nsThread.cpp:391

It seems like mPacketizerInput->mChannels is zero in these crashes, which triggers the exception. Chun-Min, it seems that you modified this code recently, can you please have a look?

Comment 1

[Ryan VanderMeulen [:RyanVM]]

This is showing up in the Beta97 topcrash list.

Comment 2

[C.M.Chang[:chunmin]]

The channel count should be clamped between the 1 and the max-channel provided by the device, before it reached to the PacketizeAndProcess. Weird.

We have assertions in AudioPacketizer and before initializing AudioPacketizer if the channel count is 0, but the MOZ_ASSERT doesn't work in beta. We should check the mRequestedInputChanne as well in AudioInputProcessing's ctor and SetRequestedInputChannelCount.

The crashes are only on the Windows for now. I guess some weird audio device may return 0 as its input channel count. We check this on mac but we don't check it on Windows. This might be the reason of why the problem are on Windows only. However, I don't see any crash on Linux but Linux doesn't check it as well. Anyway, maybe we should check the channel count in CubebDeviceEnumerator.

Comment 3

[Gabriele Svelto [:gsvelto] (PTO)]

IIRC that check on macOS was introduced in response to bug 1613156, so maybe we have a similar situation on Windows.

Comment 4

[C.M.Chang[:chunmin]]

I suspect ApplySettings should be executed before here so the AudioInputProcessing::SetRequestedInputChannelCount can run before AudioInputProcessing::Start. Otherwise mRequestedInputChannelCount could be 0 if cubeb creates a 0-channel device (comment 2). I am going to write a patch for it.

Comment 5

[C.M.Chang[:chunmin]]

(In reply to C.M.Chang[:chunmin] from comment #4)

I suspect ApplySettings should be executed before here so the AudioInputProcessing::SetRequestedInputChannelCount can run before AudioInputProcessing::Start.

hmm... this approach would need to take care MediaTrackGraphImpl::ReevaluateInputDevice() since AudioInputProcessing::SetRequestedInputChannelCount will call it.

Comment 6

[C.M.Chang[:chunmin]]

The patches in bug 1751443 should be able to suppress the crash, while bug 1751778 is more like a preparing step for comment 4, which will refactor the code a bit. I'll file the changes in different bugs so it's easier to monitor the crash rate between these changes.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

No crashes from 97.0b9. Calling this fixed by bug 1751443.