Assigning to concern owner from Predator results --
Regression information is not available. The result is the blame information. 

Author: Lei Zhang
Project: chromium-pdfium
Changelist: https://pdfium.googlesource.com/pdfium.git/+/cfb6f46473777e444c8124318aa78d33aae64459
Time: Mon Mar 20 15:46:06 2017 -0700
The CL last changed line 2463 of file tif_ojpeg.c, which is stack frame 3. 

Author: Bo Xu
Project: chromium-pdfium
Changelist: https://pdfium.googlesource.com/pdfium.git/+/fdc00a7042d912aafaabddae4d9c84199921ef23
Time: Tue Oct 28 23:03:33 2014 -0700
The CL last changed line 789 of file tif_ojpeg.c, which is stack frame 4. 

Author: Bo Xu
Project: chromium-pdfium
Changelist: https://pdfium.googlesource.com/pdfium.git/+/fdc00a7042d912aafaabddae4d9c84199921ef23
Time: Tue Oct 28 23:03:33 2014 -0700
The CL last changed line 730 of file tif_ojpeg.c, which is stack frame 5. 

Author: Bo Xu
Project: chromium-pdfium
Changelist: https://pdfium.googlesource.com/pdfium.git/+/fdc00a7042d912aafaabddae4d9c84199921ef23
Time: Tue Oct 28 23:03:33 2014 -0700
The CL last changed line 991 of file tif_read.c, which is stack frame 6. 

Author: Nicolas Pena
Project: chromium-pdfium
Changelist: https://pdfium.googlesource.com/pdfium.git/+/c760024a54b92a2e091cfcae4d9bbb7d52e66374
Time: Thu Jul 20 14:35:29 2017 -0400
The CL last changed line 867 of file tif_getimage.c, which is stack frame 7. 

Author: Bo Xu
Project: chromium-pdfium
Changelist: https://pdfium.googlesource.com/pdfium.git/+/fdc00a7042d912aafaabddae4d9c84199921ef23
Time: Tue Oct 28 23:03:33 2014 -0700
The CL last changed line 533 of file tif_getimage.c, which is stack frame 8. 

Author: thestig
Project: chromium-pdfium
Changelist: https://pdfium.googlesource.com/pdfium.git/+/fcf61b39ee597c73e80ba789833fb7fe49878422
Time: Thu Jun 09 18:29:35 2016 -0700
The CL last changed line 453 of file ccodec_tiffmodule.cpp, which is stack frame 9.

Suspecting Commit#
https://pdfium.googlesource.com/pdfium.git/+/c760024a54b92a2e091cfcae4d9bbb7d52e66374

@npm -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

hnakashima@ can you take a look?

This is a libtiff bug.

The OJpeg (original Jpeg, tag value 0006) decoder has quadratic complexity in the number of tiles of an image. This is relevant for this test case, which has ~3600 tiles, and decoding takes an amount of time in the order of magnitude of an hour. OJpeg is rarely used, deprecated since 1992.

This bug only happens with TIFFs with OJpeg compression that are tiled (not striped) and have a large amount of tiles. Due to the rarity of these conditions, I don't think it's worth pursuing a fix.

From the header of tif_ojpeg.c:
"A disadvantage is the lack of random access to the individual striles. This is the
reason for much of the complicated restart-and-position stuff inside OJPEGPreDecode.
Applications would do well accessing all striles in order, as this will result in
a single sequential scan of the input stream, and no restarting of LibJpeg decoding
session."

When gtTileSeparate in tif_getimage.c loops through the tiles in order, it does not follow this, but rather:

  for each tile:
    for each color channel:
      TIFFReadTile()

This causes each call to TIFFReadTile to have linear complexity in the number of tiles until that one, so the total complexity is quadratic in the number of tiles.

Automatically applying components based on information from OWNERS files. If this seems incorrect, please apply the Test-Predator-Wrong-Components label.

For more information, please see https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md.

The link referenced in the description is no longer valid.

We are closing all ooms and timeouts that are unreproducible. We won't be filing such bugs in future.