Skip to content

docs: Expand FAQ about OOMs #14285

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+24 −1
Open

docs: Expand FAQ about OOMs #14285

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 24 additions & 1 deletion docs/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -105,7 +105,30 @@ We currently do not have a good way to deduplicate timeout or OOM bugs.
So, we report only one timeout and only one OOM bug per fuzz target.
Once that bug is fixed, we will file another one, and so on.

Currently we do not offer ways to change the memory and time limits.
## Can I change the default timeout and OOM for a fuzz target?

Yes, you can. For this, create a fuzz target options file named `<fuzz-target>.options`,
where `<fuzz-target>` is the executable file name of the fuzz target, in the same
directory as your `project.yaml`. The options file can contain fuzzer-specific
configuration values, such as:

```
[libfuzzer]
rss_limit_mb = 6000
Copy link
Contributor Author

@pitrou pitrou Nov 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure this is a good example value. The FAQ later says that fuzz targets should not use more than 2.5 GB RAM, but I see at least one project that bumped the limit to 6 GB.

timeout = 30
```

## My library gracefully handles allocation failures, why are OOMs reported?

OOM detection is done *not* by instrumenting memory allocation routines such as `malloc`
to have them return NULL, but using a separate watchdog thread that measures the resident
set size (RSS) on a periodic basis. Therefore, your fuzz target might successfully
allocate more than the configured max RSS, and yet get killed shortly afterwards.

The only reliable way to avoid this is for your fuzz target to use a custom allocator
that will prevent allocating more memory than a given limit. You can find a more
detailed discussion of this topic, as well as links to the solution implemented
by a specific project, in [this issue](https://github.com/google/oss-fuzz/issues/1830).

## Can I launch an additional process (e.g. a daemon) from my fuzz target?

Expand Down