Tab crashes loading a pdf file
Reported by
gustavo....@gmail.com,
Dec 2 2016
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0 Steps to reproduce the problem: 1. Load the attached pdf in chrome. 2. Wait until the tab crashes (a minute). It can be also reproduced in the last revision of pdfium (bea049784abf7c32d0b9758fc77d0e601d5c232b) trying to parse the pdf using pdfium_test. What is the expected behavior? It should not crash the current tab. What went wrong? It seems to be allocating more and more memory until it crashes. I'm using the 'security' category since this issue could be produced by an integer overflow. The crash id is afa0155f00000000 Did this work before? N/A Chrome version: 55.0.2883.11 Channel: dev OS Version: Arch Linux Flash Version: This test case was generated using QuickFuzz.
,
Dec 2 2016
I can't reproduce this on a fresh Chrome checkout or a pdfium checkout (waited for much longer than a minute). Either way, based on looking at the crash report this doesn't look like a security bug (OOM), so I'm removing this from the security queue.
,
Dec 2 2016
So, is this pdf rendering in your fresh Chrome?
,
Dec 5 2016
,
Dec 5 2016
npm@ can you take a look and see if you can repro this?
,
Dec 5 2016
Yes, this is crashing.
,
Jan 3 2017
This PDF file is horribly malformed. Not only is its xref table wrong, but it contains this object, which references itself: 4 0 obj <</Length 4 0 R/Filter/FlateDecode>> stream All the PDF tools (qpdf, cpdf, gs) I tried on this either gave an error, crashed, or entered a loop.
,
Jan 3 2017
Yes, it is malformed, but we try to handle even malformed cases as gracefully as possible. We are crashing after trying to load for a while, which is pretty bad. Some pdf viewers also behave poorly on this file. But on my Mac, Acrobat Reader will not crash and just show up a blank page. Maybe that is what we would like to do (or at least show up some error message after not too long). Note to me: on my workstation it is showing crash tab. On my Mac, after waiting long, it showed up a black page.
,
Jan 3 2017
For instance, if I enable Skia, it renders fast. Maybe looking at what Skia does vs what we try to do can help to figure out how to optimize.
,
Jan 9 2017
,
Jan 9 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7dcb520819f004e4751051a6cc6181b717b211b1 commit 7dcb520819f004e4751051a6cc6181b717b211b1 Author: pdfium-deps-roller <pdfium-deps-roller@chromium.org> Date: Mon Jan 09 20:09:35 2017 Roll src/third_party/pdfium/ 661008dde..c589fdc5e (1 commit). https://pdfium.googlesource.com/pdfium.git/+log/661008dde735..c589fdc5e4e9 $ git log 661008dde..c589fdc5e --date=short --no-merges --format='%ad %ae %s' 2017-01-06 npm HardClip all points used when building paths BUG= 670524 , 678767 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/2619373002 Cr-Commit-Position: refs/heads/master@{#442321} [modify] https://crrev.com/7dcb520819f004e4751051a6cc6181b717b211b1/DEPS |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by ClusterFuzz
, Dec 2 2016