1487833 - Crash in nsThreadPool::Run

Status: REOPENED

(Core :: XPCOM, defect)

Description

[Mats Palmgren (inactive)]

This bug was filed from the Socorro interface and is
report bp-333de996-408a-4ca6-81e6-576860180831.
=============================================================

611 reported crashes in the past month for this signature
crashing on a runtime assert:
MOZ_RELEASE_ASSERT(r == 110)
or (less common)
MOZ_RELEASE_ASSERT(GetLastError() == 1460L) 

Most crashes are on Android, but not all.

Crashing thread is "MediaPlayback #3"

Top 10 frames of crashing thread:

0 libmozglue.so mozilla::detail::ConditionVariableImpl::wait_for mozglue/misc/ConditionVariable_posix.cpp:163
1 libxul.so mozilla::CondVar::Wait xpcom/threads/CondVar.h:74
2 libxul.so nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:219
3 libxul.so <name omitted> xpcom/threads/nsThreadPool.cpp
4 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1090
5 libxul.so wcsrtombs 
6 libxul.so nsThreadManager::GetCurrentThread xpcom/threads/nsThreadManager.cpp:422
7 libxul.so wcsrtombs 
8 libxul.so wcsrtombs 
9 libxul.so MessageLoop::ReloadWorkQueue ipc/chromium/src/base/lock_impl_posix.cc:64

=============================================================

Comment 1

[Mats Palmgren (inactive)]

In bp-0be30459-d256-4da8-8c84-7c5de0180825 the crashing thread is "MediaPDecoder #5"

Comment 2

[Nils Ohlmeier [:drno]]

While some of the crashing threads are media playback several are generic unlabeled threads. Plus in case of the crashes I looked at it looks like the thread crashes before it executing playback code. So my guess is this more a generic issue not specific to playback.

Comment 3

[Mike Hommey [:glandium]]

Looking at a few crashes, it seems there are many error conditions that don't directly involve the mozglue part of the stack traces in the crashes from comment 0 and comment 1, and the fact that the condvar waiting fails with something else than a timeout, mixed with the other types of crashes with the same signature make me thing there might be some UAF involved here, at an upper level.

Comment 4

[Pablo]

Reopening bug since there are crash reports in the last 6 months.

Comment 5

[Matthew]

Hi! Just new here. Ok, just founded this thread after seeing the same issue using "about:crashes". Seems like this crash also happens to me when using Instagram and I have three reported bugs reported regarding to the same crash. Other websites don't crash, only on Instagram.

Here's mine, the first one is from today:

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/5f0380f2-d8ed-49a4-8b3d-814560220422

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(r == 60)

Top 9 frames of crashing thread:

0 libmozglue.dylib mozilla::detail::ConditionVariableImpl::wait_for mozglue/misc/ConditionVariable_posix.cpp:152
1 XUL nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:285
2 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1167
3 XUL mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:300
4 XUL MessageLoop::Run ipc/chromium/src/base/message_loop.cc:306
5 XUL nsThread::ThreadFunc xpcom/threads/nsThread.cpp:389
6 libnss3.dylib _pt_root nsprpub/pr/src/pthreads/ptthread.c:201
7 libsystem_pthread.dylib libsystem_pthread.dylib@0x0000000000007268 
8 libsystem_pthread.dylib libsystem_pthread.dylib@0x0000000000007268 

And here's the second, happened on April 15:

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/813ab825-525f-42bc-adae-74b790220415

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(r == 60)

Top 9 frames of crashing thread:

0 libmozglue.dylib mozilla::detail::ConditionVariableImpl::wait_for mozglue/misc/ConditionVariable_posix.cpp:152
1 XUL nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:285
2 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1167
3 XUL mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:300
4 XUL MessageLoop::Run ipc/chromium/src/base/message_loop.cc:306
5 XUL nsThread::ThreadFunc xpcom/threads/nsThread.cpp:389
6 libnss3.dylib _pt_root nsprpub/pr/src/pthreads/ptthread.c:201
7 libsystem_pthread.dylib libsystem_pthread.dylib@0x0000000000007268 
8 libsystem_pthread.dylib libsystem_pthread.dylib@0x0000000000007268 

What is the problem with this bug? Is it Instagram's or in the side of Firefox. I see also same reports of this in the recent days, but not sure if its Instagram or other websites. [https://crash-stats.mozilla.org/signature/?product=Firefox&signature=nsThreadPool%3A%3ARun&date=%3E%3D2022-04-15T10%3A48%3A00.000Z&date=%3C2022-04-22T10%3A48%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#reports]

Comment 6

[Nika Layzell [:nika] (ni? for response)]

There appears to be a number of crashes (specifically on macOS) which have the Moz-Crash Reason as MOZ_RELEASE_ASSERT(r == 60), which I am guessing is from this crash: (https://searchfox.org/mozilla-release/rev/7c81015c50c463bcb70f2c469327b18f1a5d5bd5/mozglue/misc/ConditionVariable_posix.cpp#150). This lines up with the other assertion reasons in comment 0.

Not able to find much actionable from this right now, and the volume is fairly low.