Indeed. BTW if you open Chrome task manager you'll see Chromium PDF plugin eating a lot of CPU and memory - until it finally reaches the process limit at a few GB and crashes. Apparently PDFium scans the empty PDF file trying to find the header and doesn't release the memory due to a bug in the code.

The built-in PDF Viewer has a plugin component and all plugins use PPAPI. The PPAPI architecture sets a process memory limit, which IIRC is 2 GB. So any time the PDF plugin tries to use too much memory, e.g. by loading a very large PDF into memory, it will run out of memory and crash. So if you have a real PDF that's very large in size, it's just not going to work.

As for the case where the file is obviously not a PDF, it may be possible to check for that during loading and reject it without running out of memory.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

PDFs contain magic bytes at the beginning to indicate that it is a PDF and the version being used, so a large zero'd file should probably fail fast. 

If you create a small PDF (using dd if=/dev/zero seek=1000 bs=1 count=1 of=test-small.pdf) then it will fail to load with a message indicating it isn't valid. If you create an over 2 gig PDF (using dd if=/dev/zero seek=3221225472 bs=1 count=1 of=test-big.pdf) then the PDF will load for a long time and eventually the tab will crash as described. PDFium should be fast failing if the magic bytes are missing. I'll take a look into this.

Spent some time looking into this. It looks like PDFium is correctly detecting the magic header bytes not being present and failing the load. The issue is on the client side, since we are not asynchronously/lazy fetching data for the file. This is explicitly commented on in the code @ https://cs.chromium.org/chromium/src/pdf/pdfium/pdfium_engine.cc?rcl=bc34c0355b3b0d8ac282184dfb31fc107b231fe0&l=901 and apparently is related to http://code.google.com/p/chromium/issues/detail?id=59400.

So in summary, a small malformed file of this type will fail to load in PDFium with a message informing you it is bad. A 2+ GB malformed PDF will eventually crash the tab, due to overrunning the plugin memory limit and there will be no message about it being malformed. The delay in crashing is due to the PDF viewer fetching all of the file into memory, not PDFium failing to recognize early that the file is bad. I believe this is WAI.