New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 663796 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 640998
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Mac
Pri: 3
Type: Bug



Sign in to add a comment

Viewing PDFs with built-in viewer fails intermittently

Reported by ryan.p.c...@gmail.com, Nov 9 2016

Issue description

Chrome Version       : 	54.0.2840.71
URLs (if applicable) :  https://www.intricate-solutions.com/pub/viewDocument.do?key=v2_29fbc194-a69d-11e6-b07f-afa50f8e14cf

Other browsers tested:
  Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
     Safari 10.0.1: OK
    Firefox 49.0.2: OK

What steps will reproduce the problem?
(1) Open the URL given above in Chrome.

What is the expected result?
The PDF should be displayed in the built-in PDF viewer.

What happens instead?
Sometimes, a blank page with an "unhappy puzzle piece" icon displays instead (see attached screenshot).  Sometimes the PDF displays correctly, but it seems to have around an 80% failure rate.

Please provide any additional information below. Attach a screenshot if
possible.

See attached screenshot.

This is happening for both Windows and OS X users.

This may or may not be specific to certain PDFs generated by BlueBeam.

 
Screen Shot 2016-11-09 at 1.39.50 PM.png
87.2 KB View Download
We are experiencing the same.
Components: Internals>Plugins>PDF
Labels: Needs-Feedback OS-Mac
Unhappy puzzle pieces are plugin crashes. Do you have crash report IDs? https://www.chromium.org/for-testers/bug-reporting-guidelines/reporting-crash-bug
Labels: Stability-Crash
Cc: npm@chromium.org
Labels: -Needs-Feedback OS-Linux
Status: Untriaged (was: Unconfirmed)
I didn't reproduce it on Linux with Chrome 56. Chrome 54 gave me 44861d6700000000
This might be  bug 640998  in which case it should be fixed in Chrome 55.
The stack trace for my crash with 54.0.2840.100:

#0  0x00007fa8b23aef9e in CPDF_Parser::LoadCrossRefV5 ()
    at ../../third_party/pdfium/core/fpdfapi/fpdf_parser/cpdf_parser.cpp:968
#1  0x00007fa8b23b074f in CPDF_Parser::LoadCrossRefV4 ()
    at ../../third_party/pdfium/core/fpdfapi/fpdf_parser/cpdf_parser.cpp:572
#2  0x00007fa8b23ad1e7 in CPDF_Parser::LoadAllCrossRefV4 ()
    at ../../third_party/pdfium/core/fpdfapi/fpdf_parser/cpdf_parser.cpp:378
#3  0x00007fa8b23a35f1 in CPDF_DataAvail::LoadAllXref ()
    at ../../third_party/pdfium/core/fpdfapi/fpdf_parser/cpdf_data_avail.cpp:348
#4  0x00007fa8b23a1f39 in CPDF_DataAvail::IsDocAvail ()
    at ../../third_party/pdfium/core/fpdfapi/fpdf_parser/cpdf_data_avail.cpp:215
...
Labels: Needs-Bisect
It looks to be fixed in Chrome 55. I wouldn't bother (reverse) bisecting except to make sure this is  bug 650998 .
Cc: brajkumar@chromium.org
Labels: -Needs-Bisect hasbisect
Owner: thestig@chromium.org
Status: Assigned (was: Untriaged)
Bisect Information:
--------------------
Good build:54.0.2840.98
Bad build: 54.0.2840.92

Change Log:
------------
https://chromium.googlesource.com/chromium/src/+log/54.0.2840.92..54.0.2840.98?pretty=fuller&n=10000

From the above CL suspecting the below change
Review URL: https://codereview.chromium.org/2470213002 .

Confirming this issue got fixed and merged to M54 branch.

Assigning to @thestig for more information.

Comment 12 by npm@chromium.org, Nov 11 2016

 Issue pdfium:631  has been merged into this issue.
Uh, the bisect looks wrong. 54.0.2840.100 stable is still crashing here.
Mergedinto: 640998
Status: Duplicate (was: Assigned)
Bisects to https://chromium.googlesource.com/chromium/src/+log/540983ab54c3259bb9b548bfd8c1d95367fa15f2..712fc6049b32036a00ee1684bc1db726c969db59 -> comment 10 stands.

This should be fixed in Chrome 55 in a few weeks. We should have merged the fix to Chrome 54 in September, but forgot to, and now it is too late for a merge. Sorry for the inconvenience.

Sign in to add a comment