1821761 - Too many untrusted modules kept in UntrustedModulesData

Status: RESOLVED FIXED

(Firefox :: Launcher Process, defect)

Description

[Greg Stoll :gstoll]

See the logs posted here; the failing assert and call stack are:

[task 2023-03-09T04:07:42.455Z] 04:07:42 INFO - GECKO(6700) | #01: mozilla::UntrustedModulesData::AddNewLoads(mozilla::ModulesMap const&, mozilla::AutoCleanLinkedList<mozilla::ProcessedModuleLoadEventContainer>&&, mozilla::Vector<mozilla::Telemetry::ProcessedStack,0,mozilla::MallocAllocPolicy>&&) [toolkit/xre/dllservices/UntrustedModulesData.cpp:335]
[task 2023-03-09T04:07:42.470Z] 04:07:42 INFO - GECKO(6700) | #02: mozilla::UntrustedModulesProcessor::ProcessModuleLoadQueue() [toolkit/xre/dllservices/UntrustedModulesProcessor.cpp:715]
[task 2023-03-09T04:07:42.471Z] 04:07:42 INFO - GECKO(6700) | #03: mozilla::UntrustedModulesProcessor::BackgroundProcessModuleLoadQueue() [toolkit/xre/dllservices/UntrustedModulesProcessor.cpp:518]
[task 2023-03-09T04:07:42.471Z] 04:07:42 INFO - GECKO(6700) | #04: mozilla::detail::RunnableMethodImpl<mozilla::UntrustedModulesProcessor ,void (mozilla::UntrustedModulesProcessor::)(),1,0>::Run() [xpcom/threads/nsThreadUtils.h:1219]
[task 2023-03-09T04:07:42.472Z] 04:07:42 INFO - GECKO(6700) | #05: mozilla::TaskQueue::Runner::Run() [xpcom/threads/TaskQueue.cpp:266]
[task 2023-03-09T04:07:42.472Z] 04:07:42 INFO - GECKO(6700) | #06: nsThreadPool::Run() [xpcom/threads/nsThreadPool.cpp:345]
[task 2023-03-09T04:07:42.473Z] 04:07:42 INFO - GECKO(6700) | #07: nsThread::ProcessNextEvent(bool, bool*) [xpcom/threads/nsThread.cpp:1234]
[task 2023-03-09T04:07:42.473Z] 04:07:42 INFO - GECKO(6700) | #08: NS_ProcessNextEvent(nsIThread*, bool) [xpcom/threads/nsThreadUtils.cpp:477]
[task 2023-03-09T04:07:42.474Z] 04:07:42 INFO - GECKO(6700) | #09: mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) [ipc/glue/MessagePump.cpp:301]
[task 2023-03-09T04:07:42.474Z] 04:07:42 INFO - GECKO(6700) | #10: MessageLoop::RunHandler() [ipc/chromium/src/base/message_loop.cc:375]
[task 2023-03-09T04:07:42.475Z] 04:07:42 INFO - GECKO(6700) | #11: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:357]
[task 2023-03-09T04:07:42.475Z] 04:07:42 INFO - GECKO(6700) | #12: nsThread::ThreadFunc(void*) [xpcom/threads/nsThread.cpp:393]
[task 2023-03-09T04:07:42.643Z] 04:07:42 INFO - GECKO(6700) | #13: _PR_NativeRunThread(void*) [nsprpub/pr/src/threads/combined/pruthr.c:408]
[task 2023-03-09T04:07:42.654Z] 04:07:42 INFO - GECKO(6700) | #14: pr_root(void*) [nsprpub/pr/src/md/windows/w95thred.c:140]

The issue is that we assert that we don't have more than kMaxEvents entries in mEvents, but there are some places that we don't cap it to that.

This showed up intermittently while enabling debug MSIX tests, but it seems like we're just getting lucky most of the time and this could have happened before this.

Comment 1

[Greg Stoll :gstoll]

Attachment: Bug 1821761 - don't keep too many entries in UntrustedModulesData r=mhowell

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2ab406782ca9
don't keep too many entries in UntrustedModulesData r=mhowell

Comment 3

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/2ab406782ca9

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

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

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox112 to wontfix.

For more information, please visit auto_nag documentation.