Crash report: https://crash-stats.mozilla.org/report/index/8227801f-9f65-4c99-8bf6-676de0221219

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(false) (Attempt to dispatch to thread which does not usually process dispatched runnables until shutdown)

Top 10 frames of crashing thread:

0  xul.dll  mozilla::ThreadEventTarget::Dispatch  xpcom/threads/ThreadEventTarget.cpp:80
0  xul.dll  nsThread::Dispatch  xpcom/threads/nsThread.cpp:674
1  xul.dll  NS_DispatchToCurrentThread  xpcom/threads/nsThreadUtils.cpp:208
2  xul.dll  mozilla::gfx::GradientCache::NotifyHandlerEndLocked  gfx/thebes/gfxGradientCache.cpp:224
3  xul.dll  mozilla::gfx::GradientCache::LookupOrInsert  gfx/thebes/gfxGradientCache.cpp:169
3  xul.dll  mozilla::gfx::gfxGradientCache::GetOrCreateGradientStops  gfx/thebes/gfxGradientCache.cpp:272
4  xul.dll  mozilla::layers::CanvasTranslator::GetOrCreateGradientStops  gfx/layers/ipc/CanvasTranslator.cpp:522
5  xul.dll  mozilla::gfx::RecordedGradientStopsCreation::PlayEvent const  gfx/2d/RecordedEventImpl.h:3258
6  xul.dll  std::_Func_class<bool, mozilla::gfx::RecordedEvent*>::_Empty const  /builds/worker/fetches/vs/vc/tools/msvc/14.16.27023/include/functional:1283
6  xul.dll  std::_Func_class<bool, mozilla::gfx::RecordedEvent*>::operator const  /builds/worker/fetches/vs/vc/tools/msvc/14.16.27023/include/functional:15732480

From Nika in bug 1806751 comment #5:

It looks like there is some code which uses NS_DispatchToCurrentThread when on a threadpool, which is definitely broken, and is probably best fixed by someone on the graphics team figuring out what the actual behaviour it should have is.

This is the only instance I see of this particular crash so far, so apparently it isn't common.

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 AArch64 and ARM crashes on nightly

:lsalzman, could you consider increasing the severity of this top-crash bug?

For more information, please visit auto_nag documentation.

This is not actually a top crash, it just has the same signature as one (bug 1806751).

Bob, it looks like you were the one who added the threading to gfxGradientCache. Can you take a look?

As far as I remember, when this was originally added it was running on the main thread in the content process.
Then I also used it in the canvas playback, which is running in a thread pool and runs into this new assertion.

lsalzman: do you think that we could drop the GradientStops on a background thread?

nika: if not is there a simple way to submit to the current thread or pool depending on which you are in?

Maybe try just dispatching those always to the main thread? I thiiiiink it might work just fine since we're already using ThreadSafeWeakPtr/ref-counting on those.

(In reply to Bob Owen (:bobowen) from comment #5)

nika: if not is there a simple way to submit to the current thread or pool depending on which you are in?

No there is no way to submit to either the current thread or current thread pool depending on which you are in right now. If you want to have thread-like behaviour on a threadpool, I recommend creating a TaskQueue to run events on and using that instead.

https://hg.mozilla.org/mozilla-central/rev/9231302514fc

Seems like this is fairly successfully weeding out the assertions so far without noticeable collateral damage. The remaining crash signatures on Android seem to be from a completely different caller, not the gfxGradientCache.

(In reply to Lee Salzman [:lsalzman] from comment #11)

Seems like this is fairly successfully weeding out the assertions so far without noticeable collateral damage. The remaining crash signatures on Android seem to be from a completely different caller, not the gfxGradientCache.

Looks like there are/were some from Linux as well, I don't know if these have been dealt with already.

Though again these are not from GradientCache.

Yeah, the gradient cache ones seem to be fixed. Thanks for your quick work there. The remaining ones look to all be Service::Observe related, which is being addressed in bug 1806751.