@@ -105,7 +105,30 @@ We currently do not have a good way to deduplicate timeout or OOM bugs.
105105So, we report only one timeout and only one OOM bug per fuzz target.
106106Once that bug is fixed, we will file another one, and so on.
107107
108- Currently we do not offer ways to change the memory and time limits.
108+ ## Can I change the default timeout and OOM for a fuzz target?
109+
110+ Yes, you can. For this, create a fuzz target options file named ` <fuzz-target>.options ` ,
111+ where ` <fuzz-target> ` is the executable file name of the fuzz target, in the same
112+ directory as your ` project.yaml ` . The options file can contain fuzzer-specific
113+ configuration values, such as:
114+
115+ ```
116+ [libfuzzer]
117+ rss_limit_mb = 6000
118+ timeout = 30
119+ ```
120+
121+ ## My library gracefully handles allocation failures, why are OOMs reported?
122+
123+ OOM detection is done * not* by instrumenting memory allocation routines such as ` malloc `
124+ to have them return NULL, but using a separate watchdog thread that measures the resident
125+ set size (RSS) on a periodic basis. Therefore, your fuzz target might successfully
126+ allocate more than the configured max RSS, and yet get killed shortly afterwards.
127+
128+ The only reliable way to avoid this is for your fuzz target to use a custom allocator
129+ that will prevent allocating more memory than a given limit. You can find a more
130+ detailed discussion of this topic, as well as links to the solution implemented
131+ by a specific project, in [ this issue] ( https://github.com/google/oss-fuzz/issues/1830 ) .
109132
110133## Can I launch an additional process (e.g. a daemon) from my fuzz target?
111134
0 commit comments