Fuzzer out of memory errors #192
Comments
|
I found a workaround but there still seems to be a bug in the way the default value is computed. When looking into the log of runs producing an error, we can see this info message: and then the error is: It means that when running the fuzz command without any arguments, it picks a default My workaround is to manually raise the limit: |
|
Is there a solution to this? I am also having the same problem where memory usage rises constantly after every run, but no memory leaks are reported so I assume this is because libfuzzer is using more memory after each run. |
|
It would be cool to get an explanation with some insight, if anyone on the project has a good handle on how I wanted to understand, so I spun up a NOP fuzz_target to see what would happen. fuzz_target!(|do_not_use: u8| {});Here is some of the output during a fuzzing run. So, it seems the libfuzzer library does consume a good chunk of memory, until maybe it converges I guess the optimizer searching the state space keeps quite a lot of data about what has been seen and explored. |
Hi,
I am fuzzing the Rust implementation of
swf-parserwithcargo fuzz. The fuzzer is helpful and found some issues, but it crashes due to OOM (out of memory) errors about a third of the time. When looking into the input that caused this error, it seems that the OOM error is caused by the fuzzer itself, not the library.Here is the fuzz target:
You can run it yourself by cloning the repo and then running:
The OOM is caused when the fuzzer generates the following inputs:
b""(empty slice): Due to how the fuzz target is defined, the library shouldn't even be called. How is it possible to cause an OOM? This input is the most common cause of OOM.b"\x5b\x01\x06\x00\x40"this input caused an OOM error once. This is a well-formed input that works fine when executed as a unit test (it produces a tag marking the SWF file as protected, with an empty password). There's no recursion or advanced resource management going on in the lib: this just produces a struct and should not exceed the default 2GiB memory limit.Here is a log of one of the execution causing an OOM due to the empty slice:
See log
System information:
x86_64-unknown-linux-gnu)nightly-2019-11-06-x86_64-unknown-linux-gnu0.5.4(latest)The issue may still lie in my lib, but I find it very unlikely given the inputs causing the OOM errors.
The text was updated successfully, but these errors were encountered: