Out of memory when printing a special PDF
Reported by
johann.s...@gmail.com,
Jan 18 2017
|
|||||
Issue descriptionChrome Version : 51.0.2704.103 OS Version : Windows 10.0, 64 bit URLs (if applicable) : None needed, just open the attacked PDF and try to print it Chromium/CEF/JCEF : 3.2704, 32 bit (also tried with newest available JCEF version 3.2883 using Chromium version 55. What steps will reproduce the problem? 1. Open the attached BC.pdf with a chromium powered browser and try to print it What is the expected result? The PDF is printed correctly. What happens instead of that? Out of memory crash. Please provide any additional information below. Attach a screenshot if possible. First of all, I am aware that this issue is windows 32 bit specific. Also it is a speciality of Java to reduce the memory available for Chromium in such a massive way. But the same problem would also happen to Chromium if printing would produce a bigger spool file than ours. We use the Framework JCEF to embed HTML/SWF/PDF/... in our java application. When opening a rather simple and small PDF (1 page, containing only a barcode, size is about 10k) and trying to print it, we get an out of memory and the JVM crashes. Our analysis done so far point out the following behaviour (also see discussion in http://magpcss.org/ceforum/viewtopic.php?f=17&t=14829): We need to start our JVM with -Xmx1024m (also sometimes happen with -Xmx768m). This memory is reserved for the objects created by java, so the memory left for the native part (where cef/chromium is loaded and working) is rather small. When we open and print the PDF, a temporary spool file is generated with the size of 135.936K and written to the file system. This file is held in memory (I guess via "Mapped file") until it is fully written to the file system, I guess. Our process still has about 600.000K free memory which would be enough, but the biggest free memory block is at the size of 110K. See the attached screenshot "Xmx1024_beforePrint.jpg" for more details (produced with sysinternals tool "VMMAP"). Now the application tries to allocate the whole 135.936K in one block and doesn't get it because of the memory fragmentation. The native debug stack is attached in the "NativeStack.txt". I also attached a VMMAP dump created with an Xmx256m while printing to show the spool files size (see vmmap.7z, printing with this memory option worked. Memory usage can also be seen in VMMAP Screenshot "Xmx256_whilePrint.jpg"). Why does printing a simple 10K PDF file need 136.000K memory? Can't the memory be allocated in smaller bits? Are there any chromium options to make that amount of memory smaller? Can we implement a hack and build it ourselves to fix anything of these? Just to document, why the quickest options won't work for us: - We are bound to a 32 bit process because of other native DLLs we need, so 64 bit is no option for us. - Reducing the JVM reserved memory is also no option for us, our JVM application part needs that memory.
,
Jan 19 2017
Unable to reproduce the issue on Windows 10 using chrome stable version#55.0.2883.87 & latest canary#57.0.2985.0. Able to print the attached PDF document successfully . Please check the issue with clean profile & let us know your observations on the same. Thank you.
,
Jan 19 2017
,
Jan 19 2017
We did further analysis and found a comment that shows exactly the problem we have: https://cs.chromium.org/chromium/src/third_party/pdfium/fpdfsdk/fpdfview.cpp?q=fpdfview&sq=package:chromium&dr=C&l=668 Our PDF has a masked image in it and the spool file is blown up extremly. In a typical chromium usecase you don't have that problem because you have more memory available for chromium. Embedded in java, there are not 2GB memory available, it's about 600 MB and this memory is hard fragmented (the reason why you don't get 130MB memory, even if 600MB are free).
,
Jan 19 2017
Just for fun: we tried to edit the PDF manually. We opened it in a TextEditor (Notepad++), searched for the "ImageMask" and found following line: <</BitsPerComponent 1/ColorSpace/DeviceGray/Decode[0 1]/Filter/JBIG2Decode/Height 150/ImageMask true/Interpolate false/Length 155/Subtype/Image/Type/XObject/Width 1344>>stream Changing "ImageMask true" to "ImageMask false" resulted in our test usecase to work.
,
Jan 19 2017
Since this PDF contains masks you are correct that that is likely the reason for the memory issue. We rasterize PDF pages containing image masks in order to get them to print correctly (see http://crbug.com/482206 and http://crbug.com/576175 for a few examples of problems that came up before we started doing this). We do plan to look into ways we could do this better: see http://crbug.com/674771 which was filed when the comment you reference was added.
,
Jan 20 2017
I see, any plans on when this will be done? Is there a quick workaround for us to get lower memory usage? Or write the spool file in 10k parts or something like that? We might be able to patch this code in our manual build if we get a workable solution.
,
Jan 24 2017
Will hopefully get to this in the next couple of months. Unfortunately, can't give a precise time estimate on a fix as there are a few things that are higher priority and we don't yet have a good idea of how long the fix will take. For a quick workaround, if the PDF is printing correctly when you set image mask to false you may be able to try changing the logic in fpdfview; if you remove the || pPage->HasImageMask() condition in line 672 it should prevent Pdfium from transforming the page into a bitmap when it sees an image mask. This can cause weird effects for some PDFs though, as noted in the bugs I linked before.
,
Jan 24 2017
We will give the workaround a try and adapt that change for our current version. Are there any changes until Chromium 51 (currently used by us) that can influence this behaviour too?
,
Jan 26 2017
The workaround seems to work for us. We'll do further tests and see if we have new issues with it. Thx for the help!
,
Feb 8 2017
,
Apr 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5d8431f660056a90941e16f40c17c66a2e8ff485 commit 5d8431f660056a90941e16f40c17c66a2e8ff485 Author: pdfium-deps-roller@chromium.org <pdfium-deps-roller@chromium.org> Date: Thu Apr 20 22:38:26 2017 Roll src/third_party/pdfium/ e0b592236..88008a2be (52 commits) https://pdfium.googlesource.com/pdfium.git/+log/e0b592236db9..88008a2be11c $ git log e0b592236..88008a2be --date=short --no-merges --format='%ad %ae %s' 2017-04-20 dsinclair Cleanup some XFA widget code 2017-04-18 tsepez Take ContainsValue() change from base stl_util.h 2017-04-20 npm Let {Argb,Cmyk}Decode return tuples 2017-04-20 dsinclair Revert "core: allow building against system zlib" 2017-04-20 dsinclair Convert IFX_MemoryStream to CFX_MemoryStream 2017-04-20 tsepez Do not insert null node if ParseAsXDPPacket_Config fails 2017-04-20 dsinclair Move fxcrt_stream code to fx_stream file 2017-04-20 dsinclair Cleanup the fx_extension code. 2017-04-04 vmiklos core: choosen -> chosen 2017-04-19 npm Remove the friends of CPDF_FormField 2017-04-19 npm Split up CFX_DIBitmap::ConvertColorScale 2017-04-19 dsinclair Update IFX_CharIter::Clone to return unique_ptr 2017-04-19 dsinclair Rename array names to match codepage names 2017-04-19 dsinclair Cleanup codepage and charset definitions. 2017-04-19 dsinclair Cleanup the fgas_language defines 2017-04-19 dsinclair Move fde XML parser to core 2017-04-19 dsinclair Move CFGAS_Stream to CFX_SeekableStreamProxy 2017-04-18 tsepez Remove hand-written bsearch from XFA_GetAttributeEnumByName() 2017-04-18 tsepez Remove hand-written bsearch from XFA_GetAttributeByName() 2017-04-18 npm Libtiff upstream security fixes 2017-04-18 dsinclair Rename IFGAS_Stream to CFGAS_Stream 2017-04-18 dsinclair Remove IFGAS_Stream::CreateWideStringReadStream 2017-04-18 npm Libtiff upstream: _TIFFcalloc addition 2017-04-07 npm Clean up unneeded code in agg and skia driver 2017-04-18 dsinclair Fold the CFGAS_Stream subclasses in CFGAS_Stream 2017-04-18 dsinclair Codepage code into anonymouse namespace 2017-04-18 dsinclair Subclass the stream implementations from CFGAS_Stream 2017-04-18 tsepez Use unique_ptr in CFWL_NoteDriver::m_eventTargets map 2017-04-18 tsepez Use unique_ptr in JSGlobalAlternate::m_MapGlobal 2017-04-18 npm Check char sign in fx_ext.h 2017-04-18 dsinclair Rename text break files to match class names. 2017-04-18 dsinclair Update IFGAS_Stream::WriteString to take a string. 2017-04-18 dsinclair Cleanup XML buffer code 2017-04-17 tsepez Use Byte/WideString iterators 2017-04-18 dsinclair Remove unused class 2017-04-14 tsepez Use unique_ptr for m_pNormalWidget 2017-04-17 tsepez Require unique_ptr arg for CXFA_FMLexer::SetToken() 2017-04-17 rbpotter Render image masks individually instead of rendering the entire page as a bitmap in order to reduce spool sizes. 2017-04-16 thestig Remove dead barcode bitmap rendering code. 2017-04-17 tsepez Add iterators for Byte/WideStringCs. 2017-04-17 tsepez Fix buffer management issues in CFX_SAXReader. 2017-04-17 tsepez Replace indirect calls with switch in CFX_SaxReader. 2017-04-15 thestig Remove more references to GYP. 2017-04-17 tsepez Add unit test for CFX_SAXReader. 2017-04-15 thestig Roll build/ to a9eff4d. 2017-04-15 thestig Roll clang to d551679. 2017-04-13 tsepez Add ability to make StringCs from std::vector<>s. 2017-04-13 dsinclair Fold LoadFile{Read|Write} back into constructors 2017-04-13 tsepez Use vector of unique ptr in cpdf_data_avail.cpp. 2017-04-13 npm Add embeddertest for form text rendering and saving 2017-04-13 tsepez Move another opertator<<() prototype into correct .h file. 2017-04-13 vmiklos core: allow building against system zlib Created with: roll-dep src/third_party/pdfium BUG=682156,674771 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 Change-Id: I133f97f52598852812283e7ccd9b08ffaa485a22 Reviewed-on: https://chromium-review.googlesource.com/483076 Reviewed-by: <pdfium-deps-roller@chromium.org> Commit-Queue: <pdfium-deps-roller@chromium.org> Cr-Commit-Position: refs/heads/master@{#466170} [modify] https://crrev.com/5d8431f660056a90941e16f40c17c66a2e8ff485/DEPS |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by marshall@chromium.org
, Jan 18 2017Components: Internals>Printing Internals>Plugins>PDF