OOMs in the parent process don't report crashes
Categories
(Toolkit :: Crash Reporting, defect)
Tracking
()
People
(Reporter: ErichDonGubler, Unassigned)
References
Details
While triaging bug 1834195, I noticed that the reproduction steps can cause an OOM in the main Firefox process. The crash itself is not part of this bug. However, when the main process crashed in that case, I was not prompted to submit a crash report. Eek!
STR
-
Open Firefox, and ensure you have an otherwise stable set of tabs open.
-
Open your favorite application for viewing process resource usage, and identify the Firefox process group you will be working with. Note the current memory usage of Firefox. Keep the process viewer open for reference in subsequent steps.
You might also open Firefox's task manager with
Shift+Esc. If you do this, you should open in a separate window, rather than a tab in the same window for subsequent steps, as some out-of-memory errors can cause rendering to fail in one of Firefox's windows. -
Open bug 1834195's
pdf.htmlattachment (permalink). Observe that CPU memory usage rapidly climbs. -
Do something that causes an allocation in the main process. As the previous step progresses in the background, it becomes increasingly likely that this will cause an out-of-memory error that causes the main process to crash.
I am currently uncertain of a good way to do this. Will update once this is determined.
|
||
Comment 1•1 year ago
|
||
What platform where you on? On Windows the crash should be reported, on Linux it cannot be unfortunately.
|
Reporter | |
Comment 2•1 year ago
|
||
This was on my Windows 11 workstation.
|
|
||
Comment 3•1 year ago
|
||
I tried it on my machine and I could produce crashes (and the crash reporter popped up correctly). This is one of them and this is the other. I had to manually limit the size of Windows page file to trigger the bug, otherwise Windows would happily allocate a gigantic page-file to accommodate for the increasing commit space request.
However I could cause a different type of crash that was much more disruptive. During my first attempt at reproducing the GPU process crashed first (see this report). However that wasn't enough to limit the runaway memory consumption, which escalated very rapidly and took down the browser, several applications I was running in the background and the Windows shell. I had to reboot the machine as I couldn't even bring up the "Run application" window or the Task Manager.
In the latter case, and in the crash you experienced, we might be seeing results of bug 1716727 being too good at keeping Firefox processes alive... leading to almost every other process in the system dying first. When that happens we won't get a crash report, as there won't be the necessary facilities to gather one.
I don't know how to address this; it has runaway memory consumption that is terrifyingly fast. On my machine it chews several GiB of commit-space per second.
Description
•