Could not find exact culprit CL using findit, regression range and code search. cc-ed developer who worked on this. please take a look and reassign if needed.

Thank you. 

It's actually running faster than 25s on my side. This is taking most of the time in FPDFBitmap_FillRect even though the first page shows blank and the other 11000+ pages don't show. Will need to see where to improve performance.

This pdf says it has a lot of pages, but no contents in the pages. We're just taking a long time to generate all of the blank pages. We can probably improve this once we start using Skia.

why P3? 
Remember that if we have a timeout during fuzzing it means ClusterFuzz is burning 
much more CPUs and gets much fewer real security bugs detected. 

Because as I said, we are timing out trying to generate a lot of blank pages, and we want to wait until we start using Skia. Is there a way to temporarily pause clusterfuzz so that it won't run this testcase for while?

>> until we start using Skia
ETA? issue pdfium:11 is 2.5 years old. 

>> a way to temporarily pause clusterfuzz
Mmm... Dunno. It still keeps finding bugs, so we should not disable it.
It just does it much less efficiently that it could due to timeouts like this one and OOMs like  issue 672177 

>> ETA? issue pdfium:11 is 2.5 years old.
You can ask the owner of that bug.

>> Mmm... Dunno. It still keeps finding bugs, so we should not disable it.
Where did I say disable clusterfuzz? I said stop temporarily stop it from running inputs which will cost it lots of resources and which we know are not yet fixed.

raising to P2. This may actually be closer to P1: with the new pdf corpus that I've just uploaded there are lots more timeouts. ClusterFuzz won't report them until this one is fixed. And so this timeout blocks us from finding more security bugs. 

>> I said stop temporarily stop it from running inputs which will cost it lots of resources

We don't know any way to do this.
Fuzzers are too smart -- they will keep re-discovering slow inputs. 

>> ClusterFuzz won't report them until this one is fixed. And so this timeout blocks us from finding more security bugs.

If it doesn't report other bugs until a different bug is fixed, that sounds more like a clusterfuzz bug.

>> If it doesn't report other bugs until a different bug is fixed
This applies only to timeouts and OOMs. 
We don't know of any good way to de-duplicate these kinds of bugs,
so we are forced to report just one timeout and one OOM at a time.
Also, if one timeout bug does not get fixed there is little reason to report another one. :)

Are there samples of other pdfium_fuzzer timeouts? If the issue is always "pdfium_fuzzer spends too much time rendering 10K blank pages" then why don't we limit it to only render the first 10 instead? That's still plenty of room to find lots of bugs.

>> Also, if one timeout bug does not get fixed there is little reason to report another one.

Uhhh we have fixed several timeouts. But I saw something now that I missed before, so I can fix this now.

Attaching a fresh batch of non-deduplicated timeout reproducers. 
As I explained in #11 ClusterFuzz will file only one such timeout bug at a time. 

Deleted: more-pdfium-timeouts.tgz 22.3 KB

more-pdfium-timeouts.tgz 22.3 KB Download

The following revision refers to this bug:
  https://pdfium.googlesource.com/pdfium/+/c467d4619ebe0bae9a87b667ca9a06f576138f68

commit c467d4619ebe0bae9a87b667ca9a06f576138f68
Author: Nicolas Pena <npm@chromium.org>
Date: Wed Mar 15 21:35:55 2017

Reset tree traversal when we think we're at the start

If the PDF declares it has a gazillion pages when it does not, we just start
traversing again from the start. This CL fixes that.

BUG= chromium:680222 

Change-Id: Ie9b55abc0aaa372429b3d995a7e1e7ab58fb7965
Reviewed-on: https://pdfium-review.googlesource.com/3060
Commit-Queue: Nicolás Peña <npm@chromium.org>
Reviewed-by: dsinclair <dsinclair@chromium.org>

[modify] https://crrev.com/c467d4619ebe0bae9a87b667ca9a06f576138f68/core/fpdfapi/parser/cpdf_document.cpp
[modify] https://crrev.com/c467d4619ebe0bae9a87b667ca9a06f576138f68/core/fpdfapi/parser/cpdf_document_unittest.cpp

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/704aef7d3e590faa7af12dc6e9a20fbf947906d8

commit 704aef7d3e590faa7af12dc6e9a20fbf947906d8
Author: pdfium-deps-roller <pdfium-deps-roller@chromium.org>
Date: Thu Mar 16 00:41:10 2017

Roll src/third_party/pdfium/ 0029fb25b..c467d4619 (6 commits)

https://pdfium.googlesource.com/pdfium.git/+log/0029fb25b9b6..c467d4619ebe

$ git log 0029fb25b..c467d4619 --date=short --no-merges --format='%ad %ae %s'
2017-03-15 npm Reset tree traversal when we think we're at the start
2017-03-15 tsepez Use map of unique_ptr in cxfa_textparser.
2017-03-15 tsepez remove CFX_ArrayTemplate from fxet_list.
2017-03-15 thestig Refactor some CPDF_ColorSpace code.
2017-03-15 thestig Clean up more CPDF_PSEngine code.
2017-03-15 tsepez Fix botch introduced at 193e6ca, try 2.

Created with:
  roll-dep src/third_party/pdfium
BUG= 680222 

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, see:
http://www.chromium.org/developers/tree-sheriffs/sheriff-details-chromium#TOC-Failures-due-to-DEPS-rolls

TBR=dsinclair@chromium.org

Review-Url: https://codereview.chromium.org/2757443002
Cr-Commit-Position: refs/heads/master@{#457287}

[modify] https://crrev.com/704aef7d3e590faa7af12dc6e9a20fbf947906d8/DEPS

ClusterFuzz has detected this issue as fixed in range 457263:457296.

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

Fuzzer: libfuzzer_pdfium_fuzzer
Job Type: libfuzzer_chrome_msan
Platform Id: linux

Crash Type: Timeout (exceeds 25 secs)
Crash Address: 
Crash State:
  pdfium_fuzzer
  
Sanitizer: memory (MSAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=427783:427885
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=457263:457296

Reproducer Testcase: https://clusterfuzz.com/download/AMIfv94uajzIp5t_QkGTDatFK4iFneXFx6bpfIMMSOcyqBx-NRpZjoEF4H8CwDOX1QCBsJSsDxkq222hT31Oc4zIWsQJl7VvQQ1aZz7ABqqZ2aoO8_0ZJCUV3wVeA-tlYHG8TRQZLsIvftceGwLGyWxKNRYjvOYpbpyA_VUS06rhDxCbsALCG9i5HiQ68pABYM-atINoHAQQOOLUVxwdmGO6SdvLnLGOa6N5n0f4ZN9_NuxehHm-nlur5Ejzo-s-4xXw5mQThwdU0IyIoZTe-EXfGSm-84uIi_5sgoNU8e_rzhhQsWSR7eVUPI-MLSvtVZJzcNoEJlY08gvZOjSW6iHMmTho3fX_v6DbM_xh6NQFc5gWXmpiAEY?testcase_id=4809791206850560


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 4809791206850560 is verified as fixed, so closing issue.

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