Bisected to r576004 "Roll src/third_party/pdfium 89063ecda876..30688fb1c434 (4 commits)"
No idea what commit to suspect inside since all are related to the parser.
Landed in 69.0.3496.0

BTW, Chrome spends several seconds to open it on a fast computer (i7 4.4 GHz, 32MB RAM, SSD), but Adobe Acrobat does it in half a second, and SumatraPDF in like 100ms, which is virtually instantaneous. Apparently, Chrome loads the entire file, which shouldn't be necessary to display the first few visible pages.

In debug builds, this causes an assertion failure in CPDF_CrossRefTable::AddCompressed().

https://pdfium.googlesource.com/pdfium.git/+/30688fb1 added some sanity checks, and now they are failing. The sanity check is for object numbers in the PDF vs the limit:

// A limit on the maximum object number in the xref table. Theoretical limits
// are higher, but this may be large enough in practice.
static const uint32_t kMaxObjectNumber = 1048576;

This PDF has an object numbered 1713470. It probably does not have 1713470 objects, but the numbers can be non-consecutive. I'll just bump it up for now.

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

commit 590cc0adffd85b7c3415f9f1b03a5355fef665d5
Author: Lei Zhang <thestig@chromium.org>
Date: Thu Nov 29 23:59:31 2018

Bump up |kMaxObjectNumber|.

Its current value does not work for some PDFs in the wild.

BUG= chromium:910009 

Change-Id: I186111ee356bb8b8213ff6bd2505236895a9fe3c
Reviewed-on: https://pdfium-review.googlesource.com/c/46090
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>

[modify] https://crrev.com/590cc0adffd85b7c3415f9f1b03a5355fef665d5/core/fpdfapi/parser/cpdf_parser.h

Will be fixed on Canary channel in a day or two. Fix will reach users in either Chrome 72 or 73.

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

commit 38c448a6131c6808c935fa8e79027872b96f34af
Author: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Date: Fri Nov 30 03:57:33 2018

Roll src/third_party/pdfium f737d4bdb38d..75a486e0a03a (4 commits)

https://pdfium.googlesource.com/pdfium.git/+log/f737d4bdb38d..75a486e0a03a


git log f737d4bdb38d..75a486e0a03a --date=short --no-merges --format='%ad %ae %s'
2018-11-30 thestig@chromium.org Export defines to dependents of the "pdfium" target.
2018-11-29 thestig@chromium.org Bump up |kMaxObjectNumber|.
2018-11-29 thestig@chromium.org Make CBC_SymbolInfo::Lookup() return a const pointer.
2018-11-29 thestig@chromium.org Fix WideString() vs {} confusion in fxbarcode.


Created with:
  gclient setdep -r src/third_party/pdfium@75a486e0a03a

The AutoRoll server is located here: https://autoroll.skia.org/r/pdfium-autoroll

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

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.



BUG= chromium:910009 , chromium:910198 
TBR=dsinclair@chromium.org

Change-Id: I84cd9d7ccecc0acb72b8e8fe91394b486affea8f
Reviewed-on: https://chromium-review.googlesource.com/c/1356130
Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#612552}
[modify] https://crrev.com/38c448a6131c6808c935fa8e79027872b96f34af/DEPS

Will be fixed in Chrome 73.