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>
diff --git a/core/fpdfapi/parser/cpdf_parser.h b/core/fpdfapi/parser/cpdf_parser.h
index 83d722f..6d0b9b5 100644
--- a/core/fpdfapi/parser/cpdf_parser.h
+++ b/core/fpdfapi/parser/cpdf_parser.h
@@ -48,7 +48,10 @@
// 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;
+ // Note: This was 1M, but https://crbug.com/910009 encountered a PDF with
+ // object numbers in the 1.7M range. The PDF only has 10K objects, but they
+ // are non-consecutive.
+ static constexpr uint32_t kMaxObjectNumber = 4 * 1024 * 1024;
static const size_t kInvalidPos = std::numeric_limits<size_t>::max();
