1901752 - Crash in [@ mozilla::(anonymous namespace)::ConfigureVideoEncoderSettings]

Status: RESOLVED FIXED

(Core :: WebRTC, defect)

Description

[BugBot [:suhaib / :marco]]

Crash report: https://crash-stats.mozilla.org/report/index/f2a3b4d9-d1e4-4ee3-9da4-813550240604

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(parsedProfileLevelId)

Top 10 frames of crashing thread:

0  XUL  mozilla::  dom/media/webrtc/libwebrtcglue/VideoConduit.cpp:220
0  XUL  mozilla::WebrtcVideoConduit::OnControlConfigChange  dom/media/webrtc/libwebrtcglue/VideoConduit.cpp:724
1  XUL  mozilla::WatchManager<mozilla::WebrtcVideoConduit>::PerCallbackWatcher::Notify const  xpcom/threads/StateWatching.h:251
1  XUL  mozilla::detail::RunnableFunction<mozilla::WatchManager<mozilla::WebrtcVideoConduit>::PerCallbackWatcher::Notify  xpcom/threads/nsThreadUtils.h:548
2  XUL  mozilla::SimpleTaskQueue::DrainTasks  xpcom/threads/TaskDispatcher.h:44
3  XUL  mozilla::TaskQueue::DrainDirectTasks  xpcom/threads/TaskQueue.cpp:319
3  XUL  {virtual override thunk}  xpcom/threads/TaskQueue.cpp
4  XUL  mozilla::AutoTaskDispatcher::TaskGroupRunnable::MaybeDrainDirectTasks  xpcom/threads/TaskDispatcher.h:243
4  XUL  mozilla::AutoTaskDispatcher::TaskGroupRunnable::Run  xpcom/threads/TaskDispatcher.h:226
5  XUL  mozilla::TaskQueueWrapper<  dom/media/webrtc/libwebrtcglue/TaskQueueWrapper.h:100

By querying Nightly crashes reported within the last 2 months, here are some insights about the signature:

• First crash report: 2024-06-04
• Process type: Content
• Is startup crash: No
• Has user comments: No
• Is null crash: Yes - 2 out of 3 crashes happened on null or near null memory address

By analyzing the backtrace, the regression may have been introduced by a patch [1] to fix Bug 1891664.

[1] https://hg.mozilla.org/mozilla-central/rev?node=3ae2900967ce

:jstutte, since you are the author of the potential regressor, could you please take a look?

Comment 1

[Andrew McCreight [:mccr8]]

This crash is in WebRTC code, but I guess some change in thread pool stuff could have riled up a latent issue?

Comment 2

[Jens Stutte [:jstutte]]

(In reply to Andrew McCreight [:mccr8] from comment #1)

This crash is in WebRTC code, but I guess some change in thread pool stuff could have riled up a latent issue?

Hmm, In this crashreport the nsThreadPool changes were not yet present and it is showing the same diagnostic assertion. The bot looks back only 2 months, but the history is longer.

Comment 3

[Andrew McCreight [:mccr8]]

50% of the crashes (3 out of 6) in the last 6 months (ignore one duplicate install time) happened since the 20240604094831 build which feels like a possible regression, even if technically it happened before. With crash volume this low, it is hard to know what is a regression and what is a fluke.

Comment 4

[Andrew McCreight [:mccr8]]

Anyways, WebRTC people are probably better to triage this than XPCOM, even if it does turn out to be due to threadpool changes.

Comment 5

[Andreas Pehrson [:pehrsons]]

Unclear why it thought of nsThreadPool -- because nsThreadPool::Run is on the stack? We'll take this.

Dan, could this be bug 1900114? It fits with when this increase in crash rate started. I'm not sure exactly how it propagates an empty level id from sdp but if those strings are all empty here the string stream would produce "000000", which is not parsable.

Tentatively marking as regressor.

Comment 6

[Byron Campen [:bwc]]

This is probably a dupe of bug 1901160, right?

Comment 7

[Dan Baker[:dbaker]]

Looks like the same location, without seeing the SDP I'm unable to give a 100% but it's highly probable to be the same issue that bug 1901160 resolves.