Closed Bug 1749281 Opened 7 months ago Closed 7 months ago

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

Categories

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

All
Windows
defect

Tracking

()

RESOLVED FIXED
98 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox96 --- unaffected
firefox97 + fixed
firefox98 + fixed

People

(Reporter: gsvelto, Assigned: chunmin)

References

Details

(Keywords: crash)

Crash Data

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?

Flags: needinfo?(cchang)

This is showing up in the Beta97 topcrash list.

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.

Flags: needinfo?(cchang)

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

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.

Assignee: nobody → cchang
Priority: -- → P1

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

Depends on: 1751443
Depends on: 1751778

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.

Depends on: 1751963
No longer depends on: 1751778

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

Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → 98 Branch
You need to log in before you can comment on or make changes to this bug.