1982199 - Crash in [@ mozilla::CancelIdleMemoryCleanupTimerAndRunner]

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[BugBot [:suhaib / :marco]]

Crash report: https://crash-stats.mozilla.org/report/index/b5b8e7f8-3276-42bf-8873-f68020250806

Reason: SIGSEGV / SEGV_MAPERR

Top 10 frames of crashing thread:

0  libxul.so  mozilla::CancelIdleMemoryCleanupTimerAndRunner  xpcom/threads/TaskController.cpp:881
0  libxul.so  mozilla::ScheduleIdleMemoryCleanup  xpcom/threads/TaskController.cpp:917
0  libxul.so  mozilla::CheckIdleMemoryCleanupNeeded  xpcom/threads/TaskController.cpp:990
1  libxul.so  mozilla::TaskController::MayScheduleIdleMemoryCleanup  xpcom/threads/TaskController.cpp:1064
1  libxul.so  nsThread::ProcessNextEvent  xpcom/threads/nsThread.cpp:1198
1  libxul.so  NS_ProcessNextEvent  xpcom/threads/nsThreadUtils.cpp:480
2  libxul.so  mozilla::ipc::MessagePump::Run  ipc/glue/MessagePump.cpp:107
3  libxul.so  MessageLoop::RunInternal  ipc/chromium/src/base/message_loop.cc:369
3  libxul.so  MessageLoop::RunHandler  ipc/chromium/src/base/message_loop.cc:362
3  libxul.so  MessageLoop::Run  ipc/chromium/src/base/message_loop.cc:344

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

• First crash report: 2025-06-05
• Process type: Content
• Is startup crash: No
• Has user comments: No
• Is null crash: Yes - all crashes happened on null or near null memory address

Comment 1

[Jens Stutte [:jstutte]]

I cannot really see how this would be possible. TaskController::Shutdown is the only place that nulls out sIdleMemoryCleanupWantsLater and that is only called during XPCOM shutdown - but the crashes show no sign of being late in shutdown.

That would mean we are early enough to be in an uninitialized state, but sIdleMemoryCleanupWantsLaterScheduled = true; happens only in ScheduleWantsLaterTimer after we ensured that sIdleMemoryCleanupWantsLater exists and is initialized.

One could suspect some race, but AFAICT TaskController is only ever used from the main thread (and I'd expect to see some TSAN failures otherwise).

Are the CPU infos revealing something potentially bogus on the hardware side?

Comment 2

[Jens Stutte [:jstutte]]

Wait, there is a path: If NS_NewTimerWithFuncCallback fails, we end up with an uninitialized sIdleMemoryCleanupWantsLater but set sIdleMemoryCleanupWantsLaterScheduled nonetheless. Now I ignore which fallible case could have happened here, but this is not clean.

Comment 3

[Jens Stutte [:jstutte]]

This seems to happen rarely enough.

Comment 4

[Gabriele Svelto [:gsvelto]]

It would be interesting to understand how NS_NewTimerWithFuncCallback() might fail but yeah, that looks definitely like the patch that's leading to this crash and sIdleMemoryCleanupWantsLaterScheduled should only be set upon success.

Comment 5

[Jens Stutte [:jstutte]]

Yeah, the question would be, what to do in the error case. I think if we just not set sIdleMemoryCleanupWantsLaterScheduled we will retry to create the timer the next time the main thread is about to fall idle after something else happened. However, if the main thread remains idle we will never purge in that case. So I'll probably propose a patch that forces an immediate purge in the failure case, just to ensure we are not seeing something caused by memory pressure we could "solve" by purging...

Comment 6

[Jens Stutte [:jstutte]]

Attachment: Bug 1982199 - Improve ScheduleWantsLaterTimer error handling. r?smaug

Normally we expect timer creation/initialization to be infallible, but there appear to be rare cases where it fails.
It would be good to understand the cause, but first of all we should honor the return value in case of error.
Note that allocations during timer init are infallible since bug 1961386, so most likely the cause is not running low on memory.

Comment 7

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1920451

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/4066a0890866
https://hg.mozilla.org/integration/autoland/rev/a778efcc8703
Improve ScheduleWantsLaterTimer error handling. r=smaug

Comment 9

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/a778efcc8703

Comment 10

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:jstutte, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox143 to wontfix.

For more information, please visit BugBot documentation.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Seeing a little bit of crash volume on ESR140? Worth an uplift there? The patch cherry-picks cleanly.

Comment 12

[Phabricator Automation]

firefox-esr140 Uplift Approval Request

• User impact if declined: Sparse random crashes that may affect both parent and content processes.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Fix is already riding on 144 beta.
• String changes made/needed: none
• Is Android affected?: no

Comment 13

[Jens Stutte [:jstutte]]

Attachment: Bug 1982199 - Improve ScheduleWantsLaterTimer error handling. r?smaug

Normally we expect timer creation/initialization to be infallible, but there appear to be rare cases where it fails.
It would be good to understand the cause, but first of all we should honor the return value in case of error.
Note that allocations during timer init are infallible since bug 1961386, so most likely the cause is not running low on memory.

Original Revision: https://phabricator.services.mozilla.com/D262593

Comment 14

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/5da021c745d1