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

Issue 682156 link

Starred by 2 users

Issue metadata

Status: Started
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug



Sign in to add a comment

Out of memory when printing a special PDF

Reported by johann.s...@gmail.com, Jan 18 2017

Issue description

Chrome 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.
 
BC.pdf
9.1 KB Download
Xmx1024_beforePrint.jpg
487 KB View Download
Xmx256_whilePrint.jpg
482 KB View Download
NativeStack.txt
3.3 KB View Download
vmmap.7z
51.9 KB Download
Cc: thestig@chromium.org scottbyer@chromium.org
Components: Internals>Printing Internals>Plugins>PDF
CCing some printing OWNERS
Cc: jmukthavaram@chromium.org
Labels: Needs-Feedback
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.

Labels: M-57
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).
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.

Cc: rbpotter@chromium.org
Labels: -Needs-Feedback
Status: Available (was: Unconfirmed)
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.
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.
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. 
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?
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!
Labels: -M-57
Owner: rbpotter@chromium.org
Status: Started (was: Available)
Project Member

Comment 12 by bugdroid1@chromium.org, 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