1646867 - Crash in [@ RtlLockHeap | HeapLock]

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P3)

Description

[Toshihito Kikuchi [:toshi]]

This bug is for crash report bp-11e364bd-88a0-4eb8-9e14-8a0b10200618.

Top 10 frames of crashing thread:

0 ntdll.dll RtlLockHeap 
1 kernelbase.dll HeapLock 
2 xul.dll SystemHeapReporter::CollectReports xpcom/base/nsMemoryReporterManager.cpp:1059
3 xul.dll mozilla::detail::RunnableFunction<`lambda at /builds/worker/checkouts/gecko/xpcom/base/nsMemoryReporterManager.cpp:1861:7'>::Run xpcom/threads/nsThreadUtils.h:557
4 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1200
5 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:481
6 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:87
7 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:308
8 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290
9 xul.dll nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137

Comment 1

[Toshihito Kikuchi [:toshi]]

Attachment: Bug 1646867 - SystemHeapSize counts only the process default heap on Windows. r=froydnj

The crash reports indicate a heap structure could be freed while
iterating over all heaps. We need to make sure it's accessible
before passing it to HeapLock, otherwise the process crashes.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/506615a2d55d
SystemHeapSize counts only the process default heap on Windows.  r=froydnj,dmajor

Comment 3

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/506615a2d55d

Comment 4

[Ryan VanderMeulen [:RyanVM]]

Is this something we should consider uplifting to ESR78?

Comment 5

[Toshihito Kikuchi [:toshi]]

The number was not big, but this was constantly happening and the fix is straightforward. I'll submit a request.

Comment 6

[Toshihito Kikuchi [:toshi]]

Comment on attachment 9157802 [details]
Bug 1646867 - SystemHeapSize counts only the process default heap on Windows. r=froydnj

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This crash was happening constantly (~10 per day) on all versions. This is caused by a third-party application that is loaded into our process and creates a custom heap.
• User impact if declined: The process randomly crashes when a user generates a memory report.
• Fix Landed on Version: 79.0a1
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The crash happens in a timing window between we get a handle of a heap and they destroy the heap. The fix is straightforward that we don't touch private heaps we don't manage.
• String or UUID changes made by this patch: None

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9157802 [details]
Bug 1646867 - SystemHeapSize counts only the process default heap on Windows. r=froydnj

Approved for 78.1esr.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/62f24832d7fd

Comment 9

[Maria Berlinger [:mberlinger], Services QA]

Hello :toshi,

Is there anything that QA can do here? If so, could you provide any STR for this?

Thanks!

Comment 10

[Toshihito Kikuchi [:toshi]]

(In reply to Maria Berlinger [:mberlinger] from comment #9)

Hello :toshi,

Is there anything that QA can do here? If so, could you provide any STR for this?

Thanks!

No manual test is needed as we don't have a local repro and we don't know which third-party application caused this (which allocates a custom heap in our process and destroy it while generating a memory report).