Crash report: https://crash-stats.mozilla.org/report/index/f8d9a7b6-2b73-4baf-b6df-228a70230711

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(aLastCallbackTime <= aCurrentNow)

Top 10 frames of crashing thread:

0  libxul.so  mozilla::dom::TimeoutManager::RescheduleTimeout  dom/base/TimeoutManager.cpp:962
0  libxul.so  mozilla::dom::TimeoutManager::RunTimeout  dom/base/TimeoutManager.cpp:905
1  libxul.so  mozilla::dom::TimeoutExecutor::MaybeExecute  dom/base/TimeoutExecutor.cpp:179
2  libxul.so  mozilla::dom::TimeoutExecutor::Notify  dom/base/TimeoutExecutor.cpp:246
2  libxul.so  {virtual override thunk}  dom/base/TimeoutExecutor.cpp
3  libxul.so  nsTimerImpl::Fire const  xpcom/threads/nsTimerImpl.cpp:675
3  libxul.so  mozilla::detail::VariantImplementation<unsigned char,   mfbt/Variant.h:309
3  libxul.so  mozilla::detail::VariantImplementation<unsigned char,   mfbt/Variant.h:318
3  libxul.so  mozilla::Variant<nsTimerImpl::UnknownCallback, nsCOMPtr<nsITimerCallback>, nsCOMPtr<nsIObserver>, nsTimerImpl::FuncCallback, nsTimerImpl::ClosureCallback>::matchN<mozilla::Variant<nsTimerImpl::UnknownCallback, nsCOMPtr<nsITimerCallback>, nsCOMPtr<nsIObserver>, nsTimerImpl::FuncCallback, nsTimerImpl::ClosureCallback>&, nsTimerImpl::Fire  mfbt/Variant.h:902
3  libxul.so  mozilla::Variant<nsTimerImpl::UnknownCallback, nsCOMPtr<nsITimerCallback>, nsCOMPtr<nsIObserver>, nsTimerImpl::FuncCallback, nsTimerImpl::ClosureCallback>::match<nsTimerImpl::Fire&  mfbt/Variant.h:857

There's an bug 1398934 for the same issue, though it's rather old so I decided to make a new bug.

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

• Top 10 desktop browser crashes on nightly

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

For more information, please visit BugBot documentation.

This doesn't really look like a top crash to me. It seems one user had 61 crashes.

I can confirm I always meet it when I watch videos on https://www.bilibili.com

Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.

For more information, please visit BugBot documentation.

Sorry for removing the keyword earlier but there is a recent change in the ranking, so the bug is again linked to a topcrash signature, which matches the following criterion:

• Top 10 desktop browser crashes on nightly

For more information, please visit BugBot documentation.

I finally found the problem: Firefox uses the system's monotonic clock to do reschedule, and for the performance of mesa1, when the kernel judges that tsc is unstable2 (AMD's tsc seems to be independent for each core, so if the program is scheduled to tsc will regress on different cores), I use the tsc=reliable kernel parameter to make the kernel use tsc as a monotonic clock source, so that the clock sometimes regresses, causing the SEGV assert to fail.

Mesa's problem has been fixed in 23.1.63, so I can remove tsc=reliable completely.