This is a meta bug to track memory usage issues found while fuzzing. This includes out of memory (OOMs) and large allocations issues.
Addressing these issues can avoid unnecessary memory consumption and in some cases lead to a better experience for the end user.
A note about memory usage bugs from the fuzzing perspective
When there is unconstrained memory usage triggered due to a bug it can affect fuzzing in multiple ways.
It can affect the current fuzzing task directly triggering a (browser process) crash due to OOM. These can be very easy to trigger due to the nature of fuzzing. Depending on the type of OOM they can be difficultly to bucket and ignore. Avoiding unnecessary browser restarts helps make fuzzing more effective. This is important in the case of all easily triggerable issues. See Fuzz Blockers.
When fuzzing it is common to run multiple instances of a fuzzer on the same hardware to maximize resource usage.
These issues also affect the system the fuzzers are running on and this can affect multiple fuzzers at once. It can trigger high system load due to paging or OOM the system which can lead to false positives or bogus results. It can also cause the automation responsible for running fuzzers on the system to fail.
In some cases it might not be realistic to enforce limits or "fix" the issue. Making allocations fallible can prevent the fuzzers from crashing the browser and might be a reasonable solution is these cases.
At the time of writing browser fuzzing typically use the following limits
- Allocation size limit: 512MB (NULL is returned for allocations greater than the limit)
- Maximum process size: 5000MB (NULL is returned after limit is reached)
- Total memory usage limit: 8000MB (Browser is terminated when limit is reached)