Chrome Crash

[ofirdev]

The following PDF crash Chrome
https://drive.google.com/file/d/0B0odzw1WMqkGM1FqQ2hwZ0FjV0k/edit?usp=sharing

Tested with Chrome 32.0.1700.72 m
Windows 7 64bit
pdf.js commit d6ed4f2

[Rob--W]

What do you mean by "crash"? Is the whole browser killed? Do you see Aw snap?

Can you reproduce the bug in a clean profile? chrome.exe --user-data-dir=%TMP%\chrome-profile --no-first-run

[ofirdev]

I see Aw snap in the tab.
I tried with a clean profile and I still see the crash.

[ofirdev]

Reported to Chrome
https://code.google.com/p/chromium/issues/detail?id=333594&thanks=333594&ts=1389515452

[yurydelendik]

Is it a regression?

[ofirdev]

It used to work but I think that it's a regression in Chrome, not pdf.js.
I mostly see it in pdfs created from latex.
I reported here hoping there might be a temp fix.

[gjuggler]

I've been seeing some stability issues with pdf.js on Chrome OSX as well (Chrome Beta 32.0.1700), which seems to have gotten worse with Chrome's latest updates. Some PDFs will cause "Aw, snap" in the default pdf.js viewer, others will be fine in the viewer but 100% "aw, snap" in the Chrome extension (where we're deploying pdf.js).

Of course pdf.js shouldn't be allowed to crash a browser, so the real issue here is Chrome. But I did some digging and was able to find a point in the pdf.js commit history where a couple of PDFs go from not-crashing to crashing on a current Chrome browser.

My approach was to do a poor man's bisect, checking out a given commit in the history and cleaning / building the local server to test a given PDF. The following was true for the test12345.pdf mentioned above, as well as http://mappaproject.arch.unipi.it/wp-content/uploads/2012/03/mappa_fronte_retro.pdf

Checking out 4ce6cb8 ("uses postMessage transfers") and running the server:

git checkout 4ce6cb8b0fa9db948516b2b738fa1503cf0ef90e; node make clean; node make web; node make server

both PDFs loaded fine via the localhost server in Chrome beta. (I used a URL like localhost:8888/web/viewer.html?file=/test/mappa_fronte_retro.pdf)

but when checking out the next commit, c8af256 ("Uses blob URL instead of data when possible"):

git checkout c8af2565f18f7f22caa3f870a15a3afa1969743d; node make clean; node make web; node make server

both PDFs regularly "aw, snap"-ed Chrome. I tested a number of commits before and after this point, and this commit (at least in my tests) seems to be the major culprit.

I've encountered all sorts of bizarre results while testing different commits in Chrome today. Chrome's tendency to crash is even more pronounced in our extension-based environment. Unfortunately, we've had to go back ~10 months (to 55d850e) to find a setup that's consistent and reliable for us.

Note that this is definitely specific to Chrome — everything works as expected for all commits in Firefox on OSX. It's disappointing that Chrome is showing such unreliable behavior when working with some fairly standard web platform components (web workers, blob URLs, etc.). But development doesn't happen in a vacuum, and it seems that some number of pdf.js changes over the past ~year, most likely in combination with Chrome's own pace of change, have led to a pretty unstable setup. Unless something changes one way or another, I wouldn't be surprised to see more and more reports of crashing tabs with pdf.js on Chrome in the future.

[timvandermeij]

@gjuggler Thank you for the detailed description! That will definitely help.

[ofirdev]

@gjuggler I've modified #4103 to disable createObjectURL in Chrome and I'm still getting "aw, snap" with the test12345.pdf file.

[gjuggler]

Hmm — maybe my comment on chromium-issues about createObjectURL was premature. But I double-checked and still do see a crash / no-crash difference between the two commits above.

[ti0ma]

Hi,

I'm using a 2 month old version of pdf.js (V 0.8.388 build 02906d7) in my project, and I have the same problem with chrome 32.0.1700.68 in windows 7 64 bits.
It worked fine in chrome 31. I hope this is useful.

Cheers

[yurydelendik]

I reported here hoping there might be a temp fix.

It will be nice to find out which functionality is causing that... not that simple. It's too intermittent. examples/helloword/ can be used to replicate the issue. So far it's known (might be false assumptions though) loading of the document or page does not cause the crash, so is drawing operations. Which points to parsing of the operator list at evaluator.js and that is intermittent. Probably connected with GC cycle.

[dravix]

I can only add that indeed is has to be something related with the rendering of the jpg, because I tested with a distinct types of PDF's and it only crashes on those with images JPG and somehow that issue is not happening on Chome/Chromium in Ubuntu.

[mfb]

Here's a case of an "aww snap" Chrome crash on Mac OS X: https://www.eff.org/document/governments-civil-complaint

[cvaught]

Here is another pdf causing the "aww snap" crash for Chrome on Mac OS X and on Windows:

https://dl.dropboxusercontent.com/u/2541471/C-6659874.pdf

[christospappas]

I've been able to stop the crash from happening by commenting out Parser.saveState in parser.js. Everything renders fine but i'm guessing saveState is needed for something :)

[sreuter]

+1 This effects every user now since the release of Chrome 32 (Stable) this Tuesday. What a bummer :-(

I think we need a quick fix here, as it will take some time for the Chrome guys to hunt this down in v8...

@christospappas Nice findings - I think it's worth to mention that you have to clear the cache/profile for documents you tried to open before this "fix", otherwise these documents will still crash.

[timvandermeij]

@yurydelendik Could you verify if the suggestion from @christospappas is causing the issue and if we can work around it?

[yurydelendik]

Everything renders fine but i'm guessing saveState is needed for something

#4119 will be removing Parser.saveState usage, and you can remove saveState usage by yourself (I don't think it's used). But in case of JavaScript engine bug, I don't think this will fix the issue. The crashes might "move" to the different documents.

[gjuggler]

I can only speak for our setup, but removing the .saveState call made all ~15 crashing PDFs we had collected begin to render without issue on Chrome 32/33.

For us this is looking like a suitable workaround until Chrome gets fixed. There seems to be good progress on identifying where in V8 this is happening.

[timvandermeij]

#4119 has been merged. Are there still problems in Chrome or are they solved now? We will keep this issue open until the upstream issue has been solved.

[Rob--W]

I have published a new version of the PDF Viewer (v0.8.884) in the Chrome Web store that is built from the latest version of PDF.js (new commits since last update: 2926974...070d77a).

I cannot reproduce the bugs reported in this thead on Chrome/33.0.1750.18 (Linux) in the previous version of the extension, so I don't know whether the update really solves the crash bugs.

[ofirdev]

@timvandermeij
After #4119 I don't see the problem with the test12345.pdf in Chrome on Windows 7.

[lucaschen]

@yurydelendik
Why is it that the version of PDF.js on the PDF.js Github Page never crashes, even on computers where my version crashes?

Also, where exactly is Parser.saveState located, and in which commit? I can't seem to find it.

[yurydelendik]

@think123, I'm not sure what you are asking, but removal of saveState happened here yurydelendik@09f8f95#diff-0b94c2e77a5259f7a728122fdbf9f46aL737 . Please pull the latest version from the https://github.com/mozilla/pdf.js locally. Also, try clearing the Chrome's cache or creating a new profile (see above). Please notice that the workaround might not work for all documents (or even hardware/software configurations) since it's not fixing the defect in the browser.

[Rob--W]

The bug in Chromium has been fixed, according to http://code.google.com/p/chromium/issues/detail?id=333594#c33.

[timvandermeij]

Closing as fixed, both in PDF.js and in Chrome.

[carltonsmith]

I am getting this issue today and I have the latest versions of Chrome and pdf.js installed

[mitar]

Latest version of Chrome is which version? Because there are multiple latest versions, depending on which update channel you are on. As far as I know their fix haven't yet been released in stable version of Chrome. And this fix by pdf.js is just a workaround.

Does it happen on all PDFs? Can you share precise which versions do you use? Does it happen with demo viewer? Can you share a link to PDF which causes problems?

[timvandermeij]

I agree with @mitar. Please provide the mentioned information in order to reopen the issue. The Chrome issue tracker seems to indicate that the fix will be included in version 33. I think 32 is the current release version.

[steveraden]

We see this broke still on Version 32.0.1700.107, but we also see this on firefox 26.0

The error in Firefox is Error: Bad end offset: 5856
}
PDFJS.version = '0.8.505';
PDFJS.build = 'da1c944';

http://www.adlerplanetarium.org/s/school_group_programs.pdf
http://www.adlerplanetarium.org/s/school_group_pricing.pdf
http://www.adlerplanetarium.org/s/school_group_procedures.pdf

I'm unclear if this included by browser/or our cloud CMS SquareSpace. See this on version on 26 and 27

[Rob--W]

@stuRad This issue is about "Aw Snap" crashes caused by an error in he V8 JavaScript engine.

Your PDF files do not cause a "crash" (Aw Snap) for me in Chromium 33.0.1750.18. Please open a new ticket for you bug.

EDIT: Reported as #4251

[timvandermeij]

Indeed. They also work fine in the development version of PDF.js, so this bug must have been fixed in the meantime. Please wait until the new version of PDF.js lands in Firefox.

[jnelson522]

I am running version 34.0.1847.11 beta-m. When I open a pdf stored in Google Drive, I can view it. When I try to print, Chrome crashes. No "Aw, snap" message.

I am able to print from Google Drive in Firefox.

Any help in diagnosing this problem?

[timvandermeij]

@jnelson522 Please open a new issue for this as it seems unrelated to the original problem filed in this issue (which has been solved in the meantime).

[yurydelendik]

@jnelson522 in best case, the process is normally goes like this:

1. find repeatable crash with really-really-high probability;
2. find out if any of the configurations worked before, e.g. with older version of chrome and/or PDF.js;
3. bisect the versions of Chrome and/or PDF.js to find first bad version.

The version change description will give you clues how to create a smaller test case or the reason for the crash. That will make it easier to report and find right people to talk to. Please join IRC #pdfjs at irc.mozilla.org for assistance.

If you cannot perform the above it's pretty much the guessing game and commenting fragments of the PDF.js code.

[halleck1]

We still see the crash with the latest released version of pdf.js and also the github version. Crash is reproducible in 32 and 33 stable versions + Canary version as of 19/03/2014. We've also downloaded Chrome 3 (from 2011) and reproduced the crash there as well. Is there any way to turn on diagnostics in pdf.js or is it only possible from Chrome side?

[Rob--W]

@halleck1 Can you provide the STR (steps-to-reproduce)? If we know how to reproduce a crash, then we can investigate it (and fix it in PDF.js or Chromium).

[halleck1]

Repro is not stable + it uses proprietary code so we would not be able to give you the sources. We can collect the crash dump but I believe that would only be helpful to the Chrome guys. Is there anything we could do from pdf.js side of things? E.g. profiling sessions records, maybe there some diagnostic tools which you know we could to collect the diagnostic info? Also, maybe you could give us the rough instructions on how to approach the investigation 'cause we have some experience with JS as well.

[yurydelendik]

Also, maybe you could give us the rough instructions on how to approach the investigation 'cause we have some experience with JS as well.

The following worked for me:

1. Enable chrome logging as specified at http://www.chromium.org/for-testers/enable-logging;
2. Add e.g. console.log('PDFJS: .....'); in points of interest in local version of pdf.js;
3. Open chrome and crash it with locally hosted pdf.js;
4. Scan chrome_debug.log for clues;
5. Repeat from 2

Initial points of interest:

• MessageHandler.send https://github.com/mozilla/pdf.js/blob/master/src/shared/util.js#L1297
• PartialEvaluator.getOperatorList loop https://github.com/mozilla/pdf.js/blob/master/src/core/evaluator.js#L482
• CanvasGraphics.executeOperatorList loop https://github.com/mozilla/pdf.js/blob/master/src/display/canvas.js#L735

[halleck1]

Woo-hoo :-) We'll try and will let you know.

[halleck1]

Sorry, our issue seems to be a red herring. The logs which we generated as per above instructions didn't show any issues, each one had entry/exit log entry.

We then had a look at WinDbg which showed that this was an out of memory exception. Now we need to try to dig down to what's causing it since Chrome profiler does not complain - it says memory used is around 8-9 Mb. We do keep in mind this is JS-related profiler so out of memory condition is probably triggered by canvas, however the image we're drawing is not too big - in the region of 500x500 pixels.

Would you know if we could have some kind of diagnostics in this area?

[Rob--W]

@halleck1 Until recently, the backing data storage of typed arrays did not show up in Chrome's developer tools (http://crbug.com/129729). This has been fixed in Chromium 35, I believe.