Out-of-memory in gfx_png_image_fuzzer |
|||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=5117994721869824 Fuzzer: libFuzzer_gfx_png_image_fuzzer Fuzz target binary: gfx_png_image_fuzzer Job Type: libfuzzer_chrome_msan Platform Id: linux Crash Type: Out-of-memory (exceeds 2048 MB) Crash Address: Crash State: gfx_png_image_fuzzer Sanitizer: memory (MSAN) Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=395689:395794 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5117994721869824 Issue filed automatically. See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md for more information.
,
Dec 4
Unable to provide possible suspect using predator, CL and Code Search. Could someone please look into the issue. Thanks...
,
Dec 4
Leon, would you be interested to take a look? Note that this is MSan build which has a big memory overhead, so the report might be not very relevant. If it's just a very big image being passed in, we may end up with adding a sanity check to the fuzz target code.
,
Dec 4
,
Dec 5
Is there a way to get a better stack trace? This is a very large image, so I suspect it just requires a lot of memory to decode. (This shares an IHDR with issue 880956 - the image is 65440 x 4000.) I'm not sure where exactly this particular allocation is coming from, but we'll need to allocate much more to decode the entire image.
,
Dec 11
scroggo@, I'm afraid we don't have a good way to give a better stacktrace for this. I've been trying to reproduce the crash with ASan build locally, as ASan should print memory profile for OOMs, but haven't succeeded :( I've noticed though that at some point there is `malloc(1047040000)` call happening. But don't have a stracktrace for that either.
,
Dec 11
You haven't been able to reproduce? I'm pretty sure I reproduced; doing so just didn't give me any useful information. > I've noticed though that at some point there is `malloc(1047040000)` > call happening. That is the pixel memory for the SkBitmap we'll create. As in https://bugs.chromium.org/p/chromium/issues/detail?id=880956#c8, this is much larger than the 2129Mb that causes a problem for the fuzzer.
,
Dec 11
> You haven't been able to reproduce? Yeah, but I've been using ASan (AddressSanitizer) build, not MSan (MemorySanitizer). Looking at your comment in issue 880956 though, it seems like you'd expect it go OOM with ASan as well, right? Matt / Kostya, what would be a good way to debug OOM crashes? Is there any way to get a memory profile similar to what ASan can provide?
,
Dec 12
I think ASan is the best way. What does peak memory usage look like with ASan? One other approach that is hit-or-miss is to set a virtual memory ulimit and look at the stack trace of the OOM crash.
,
Dec 13
Thanks, Matt! For me, peak memory usage with ASan was about 200MB. However, when I tried setting up -rss_limit_mb=200, I was getting OOM with malloc(1GB) and without memory profile :/ |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ClusterFuzz
, Dec 4Labels: ClusterFuzz-Auto-CC