[PDFBOX-4472] Thread stuck in SoftReferenceCache.get

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.0.2 JBIG2
• Fix Version/s: 3.0.3 JBIG2
• Component/s: JBIG2
• Assignee: Tilman Hausherr
• Reporter: Arnaud Jeansen
• Created: 25/Feb/19 16:10
• Updated: 18/Dec/19 18:58
• Resolved: 02/Mar/19 12:22

Description

We use pdfbox-jbig2 3.02 in a multi-threaded environment, and the SoftReferenceCache implementation is a problem because of its usage of an unsynchronized WeakHashMap.

Today, we found two threads blocking each other with the same stack trace:

pool-95-thread-1 - priority:5 - threadId:0x00007f882c109800 - nativeId:0x3d81 - nativeId (decimal):15745 - state:RUNNABLE
stackTrace:
java.lang.Thread.State: RUNNABLE
at java.util.WeakHashMap.get(WeakHashMap.java:403)
at org.apache.pdfbox.jbig2.util.cache.SoftReferenceCache.get(SoftReferenceCache.java:40)
at org.apache.pdfbox.jbig2.JBIG2ImageReader.read(JBIG2ImageReader.java:243)
at javax.imageio.ImageReader.read(ImageReader.java:939)
at sun.reflect.GeneratedMethodAccessor3824.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.icepdf.core.pobjects.graphics.images.JBig2Decoder.decodeJbig2(JBig2Decoder.java:161)
at org.icepdf.core.pobjects.graphics.images.JBig2Decoder.decode(JBig2Decoder.java:80)
at org.icepdf.core.pobjects.graphics.images.ImageStream.getImage(ImageStream.java:94)
at org.icepdf.core.pobjects.graphics.images.references.ImageStreamReference.call(ImageStreamReference.java:74)
at org.icepdf.core.pobjects.graphics.images.references.ImageStreamReference.call(ImageStreamReference.java:40)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

Locked ownable synchronizers:
- <0x0000000600019a48> (a java.util.concurrent.ThreadPoolExecutor$Worker)

I couldn't manage to write a unit test to reproduce the problem unfortunately. But the patch is straightforward and attached to this ticket.