We got repeatedly following Stacktraces while crashing the vm:

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j sun.awt.color.CMM.cmmGetProfileData(J[B)I+0
j java.awt.color.ICC_Profile.getData()[B+35
j org.zefer.pd4ml.pdf.h$_h.o00000()V+132
j org.zefer.pd4ml.pdf.c.OÒ0000()I+40
J org.zefer.pd4ml.pdf.c.ø00000()V
j org.zefer.pd4ml.pdf.c.close()V+12
j org.zefer.pd4ml.pdf.PD4Device.dispose()V+23
j org.zefer.pd4ml.pdf.PD4Device.finalize()V+1
v ~StubRoutines::call_stub
J java.lang.ref.Finalizer.invokeFinalizeMethod(Ljava/lang/Object;)V
J java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;)V
J java.lang.ref.Finalizer$FinalizerThread.run()V
v ~StubRoutines::call_stub

#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x000000381ce7b59b, pid=32323, tid=1082612032
#
# JRE version: 6.0_24-b07
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19.1-b02 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libc.so.6+0x7b59b] memcpy+0x15b
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

--------------- T H R E A D ---------------

Current thread (0x0000000040cb4800): JavaThread "Finalizer" daemon [_thread_in_native, id=32330, stack(0x0000000040775000,0x0000000040876000)]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000000

Does anybody has a glue about the reason?

PD4ML is 100% Java application, so "in theory" it cannot crash JVM. As a rule such fatal crashes are caused by inconsistencies in JDK installation or by JVM bugs (specific for a particular platform).

I googled for similar stack traces - the only thing I suspect is that java.awt.color.ICC_Profile.getData() is not thread safe. Did you face with the problem when the application was under a heavy load (multiple simultaneous requests)?

The problematic method is called for PNG images and only for PNGs have ICC color profile. Probably there is a "killer" PNG image, your JVM instance is not able to deal with. Could you please try to identify it?

Depending on your feedback we'll produce a test version of PD4ML with synchronized ICC_Profile.getData() calls and with a possibility to disable the calls at all (it is a good practice to have image color profiles embedded to PDF, but it is not mandatory).

Beacause we get repeatedly the same problem with the same stacktrace.

At the end of the render method of the PD4ML class the dispose method of the PD4Device class will be called.
This method calls the close method on the PD4Device member of type "c" and sets the "c" reference to null.
So if the dispose method gets called twice calling finalize on PD4Device, the c.close method should not be called again , should it?
So why will the c.close method be called during finalyze?
Any idea?
Kindly
Lutz

In the actual development branch (and in v370fx2) the method is implemented safe way.

public void dispose() {
		if ( this.pdfWriter != null ) {
			this.pdfWriter.close();
			this.pdfWriter = null;
		}
			
		if ( this.outputStream != null ) {
			try {
				this.outputStream.close();
				this.outputStream = null;
			} catch (IOException e) {
			}
		}
	}

(I removed a couple of debug output lines)

But I do not believe a repeating output stream closing may cause VM crash.

As I wrote in the previous post, it crashes by an attempt to instantiate a color profile, extracted from an PNG image. The color profiles are handled by a native DLL, whose error crashes the JVM.

I think, not the output stream is the problem but the instance of class "c" , which is actually a PrintWriter.
see:
j org.zefer.pd4ml.pdf.c.close()V+12
j org.zefer.pd4ml.pdf.PD4Device.dispose()V+23
If you have a look onto the stacktrace:
The finalyzer thread calls the finalyze/dispose method. Why will the c.close() method be called at all. The reference to the pdfWriter instance is or should at least be null, because the dispose method must have been called at the end of the render method of the PD4ML class.
Could it be that there are more than one instance of PD4Device in use?
Kindly
Lutz

To generate a table of contents (only if the doc has <pd4ml:toc> tag), PD4ML creates a fake PDF device to predict page break positions. The device instance is disposed by finalize() method. It looks like the stack trace is produced by finalizing of the fake device.

What can we do to get rid of this? Can you please create a patch?
Kindly
Lutz

In one of the previous posts I asked you to try to identify the image, which crashes the VM. It would help us to find a solution.

If it happens with any PNG image, it is definitely a inconsistency/configuration problem of your JDK.

In any case we have a possible workaround: to (conditionally) disable color profiles extraction. But it would be better to avoid that.

The only picture we have inside the toc is the one I attached to this posting.
But I think that the picture is not the problem because we get the pdf document without error.
And my analysis showed that between the the download of the pdf and the crash were roundabout 50 minutes. So I think that the problem lies in the fact that the PD4Device with its related java resources were kept for that time frame, but the related native resources (profile data) were gone.
I would suggest to dispose the second PD4Device too.
Kindly
Lutz

> between the the download of the pdf and the crash were roundabout 50 minutes

Ok, now the picture is a bit more clear for me. So it looks like JVM releases resources, allocated by native DLLs, before the Java class is actually garbage collected. It is strange that the garbage collecting makes that long pause - on the other hand the Java spec does not limit the time.

Next week we plan to release an updated version - we'll add a workaround for the issue.