Hi!
Our customer reported that our java client application crashes when we try to print specific PDFs.
We could reproduce that problem with the detailed MainFrame application and the PDF given by the customer.
We must not append the failing PDF, because our customer is a hospital and the PDF contains patient sensitive data.
I will provide an image containing blacked out screenshots and if you need more informations, I can support you with them on contact.
Error messages:
JVM crashes when printing, the JCEF Logfile prints an Out of memory error (logfiles will be appended):
[0110/161653:FATAL:memory_win.cc(38)] Out of memory, size = 139177987
Details:
Windows 10 64 bit
JDK 1.8.0_60 32 bit
JCEF version: 2704 32 bit compiled release version (tried upgrading to a newer version but stopped due to the crashpadhandler error: https://bitbucket.org/chromiumembedded/ ... issues/249 )
Used JVM arguments: -Xmx1024m
Used Application arguments: --ppapi-flash-path=\\pepflashplayer32.dll --allow-outdated-plugins --noerrdialogs --log-file=D:\Temp\head_ci\CEF_DUMMY.log --log-severity=verbose
Analysis:
Due to the Java Memory model every Java process has memory reserved for java objects (defined by -Xmx JVM parameter), the rest is used for native memory (loaded DLLs, native objects, CEF/JCEF native code,...).
The more memory we use for the java heap, the less memory is available for the native part of the application.
If we use for example -Xmx1024m, the native part that CEF is allowed to use is lower than if we define -Xmx512m.
Now the following things happen:
Our client application starts a JCEF application with -Xmx1024m which is initialized correctly, loads the problematic PDF and tries to print it.
The PDF has 8 pages, its size is about 165kB, so that shouldn't be a problem.
When printing, some native code tries to allocate 139177987 bytes (about 139MB).
We could reduce the problem to the first page, printing only page 1 fails, while printing 2-8 works fine.
The special things on page 1 are two images (one on top with the logo of the hospital, one on the footer with contact details; They are marked red in the appended screenshots; the barcode is also on pages 2-8 so it should not be the problem).
Now we have following questions:
1.
On the ongoing analysis we found following issue:
https://bitbucket.org/chromiumembedded/cef/issues/1855
Can that be the same problem and would it be possible that this fix fixes our issue?
2.
Why does CEF/PDFium need 139MB to parse a 165k PDF?
Is there already a known issue or a fix in a newer pdfium/chromium/cef/jcef version?
3.
Is there anything else we can do to avoid that problem (other than open the PDF in an external viewer)?
Thx for your help, I hope we could provide you with enough informations.