Uh, is this an internal libfuzzer issue?

This is a real OOM in the target code. 
libFuzzer starts reporting it and then crashes. 
This is a Mac-specific crash (the functionality not implemented on Mac). 
My team doesn't touch libFuzzer on Mac, but the Apple folks do, 
so this will get fixed eventually. 
Let's keep this bug for the PDFium OOM. 

ClusterFuzz has detected this issue as fixed in range 465939:466777.

Detailed report: https://clusterfuzz.com/testcase?key=5415537715970048

Fuzzer: libfuzzer_pdf_jpx_fuzzer
Job Type: mac_libfuzzer_chrome_asan
Platform Id: mac

Crash Type: Sanitizer CHECK failure
Crash Address: 
Crash State:
  "((0 && "unimplemented")) != (0)" (0x0, 0x0)
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=mac_libfuzzer_chrome_asan&range=464021:464042
Fixed: https://clusterfuzz.com/revisions?job=mac_libfuzzer_chrome_asan&range=465939:466777

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5415537715970048


See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 5415537715970048 is verified as fixed, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

I don't think anything has changed that would have fixed this.

Confirmed. It does reproduce for me on Linux as well.

It looks like this Mac-specific failure went away, so this particular testcase has been marked as Fixed. However, OOM is still there, so I'm attaching another CF testcase + updating the summary.

Detailed report: https://clusterfuzz.com/testcase?key=5498346732257280

Fuzzer: libfuzzer_pdf_jpx_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: Out-of-memory (exceeds 2048 MB)
Crash Address: 
Crash State:
  pdf_jpx_fuzzer
  
Sanitizer: address (ASAN)

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5498346732257280


See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md for more information.

The input claims to have very large tile sizes. Not sure if it is possible to check the tile sizes against the input file size.

The spec says tiles can be of any size, but maybe we can just choose not to decode tiles over some size? In this case one of the tile dimensions is 12 million.

Lei, I think it would be fine to reject inputs with too large tile sizes. We have something similar in libpng fuzzer: https://cs.chromium.org/chromium/src/testing/libfuzzer/fuzzers/libpng_read_fuzzer.cc?l=129

Sure, but I think the input can also have multiple tiles. So CF will eventually find the case where there are large-ish tiles that fit just under the limit, but many of them.

Bulk-WontFixing these bugs. This was a bug on ClusterFuzz side, see bug 717534. We will start seeing new testcases auto-filed in a day or two. We can't leave these open as ClusterFuzz won't autoverify them after ClusterFuzz-Wrong label.

We have made a bunch of changes on ClusterFuzz side, so resetting ClusterFuzz-Wrong label.