Out-of-memory in blink_png_decoder_fuzzer |
|||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=6134254220869632 Fuzzer: libFuzzer_blink_png_decoder_fuzzer Job Type: libfuzzer_chrome_msan Platform Id: linux Crash Type: Out-of-memory (exceeds 2048 MB) Crash Address: Crash State: blink_png_decoder_fuzzer Sanitizer: memory (MSAN) Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=441566:441806 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6134254220869632 Issue filed automatically. See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md for more information.
,
Oct 9
,
Oct 18
scroggo@, This is OOM, however just wondering if it's related to (https://chromium.googlesource.com/chromium/src/+/1cc893851ef9ad007f4fb1eaabf58870fc634e81) and it's actionable? Thank you!
,
Dec 1
ClusterFuzz testcase 6134254220869632 appears to be flaky, updating reproducibility label.
,
Dec 1
Please ignore the last comment about testcase being unreproducible. The testcase is still reproducible. This happened due to a code refactoring on ClusterFuzz side, and the underlying root cause is now fixed. Resetting the label back to Reproducible. Sorry about the inconvenience caused from these incorrect notifications.
,
Dec 1
Please ignore the last comment about testcase being unreproducible. The testcase is still reproducible. This happened due to a code refactoring on ClusterFuzz side, and the underlying root cause is now fixed. Resetting the label back to Reproducible. Sorry about the inconvenience caused from these incorrect notifications.
,
Dec 4
,
Dec 5
Is there a way to get a longer stack trace? I'm able to reproduce, though I'm not sure where the reported allocation of 2758Mb (FWIW, locally I see 2143Mb) is coming from. The most I see coming through png_malloc_base is 261813 bytes, which isn't nearly that big. (According to [1], MSan builds have "a big memory overhead", but this would be significantly larger than the actual allocation.) That said, the image is very large: 65440 x 4000. The 261813 is for a single row of libpng's output (65440 x 4 bytes per pixel plus some padding). Eventually PNGImageDecoder would need to allocate memory for 4000 rows. That would be about a gig (1,047,040,000 bytes), which is much greater than the reported allocation. (To my surprise, I ran with -rss_limit_mb=4000 and the fuzzer no longer detects any allocations that are too big. The ImageFrame's pixel memory is much larger, as I point out above, so I don't know why that isn't caught by the fuzzer.) > This is OOM, however just wondering if it's related to > (https://chromium.googlesource.com/chromium/src/+/1cc893851ef9ad007f4fb1eaabf58870fc634e81) Not in an interesting way; that just added the fuzzer to begin with (though it was in a different place then). > and it's actionable? It might be interesting to get a more detailed stack, but I suspect there's nothing to be done here. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=911423#c3 |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by kkaluri@chromium.org
, Sep 6Labels: M-69 Test-Predator-Wrong CF-NeedsTriage