[
https://issues.apache.org/jira/browse/PDFBOX-3698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362866#comment-16362866
]
Joseph Smith commented on PDFBOX-3698:
--------------------------------------
[~tilman], the initial test using Spock is written in Groovy which internally
uses Class.forName to initialize the class. I have reproduced the issue
starting with your Java code snippet by making the following change
{code:java}
public class PDFBox3698
{
public static void main(String[] args) throws ClassNotFoundException,
InterruptedException
{
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
try {
Class.forName(COSNumber.class.getName(), true,
COSNumber.class.getClassLoader());
} catch (ClassNotFoundException ex) {
//
}
}
});
thread.start();
Class.forName(COSInteger.class.getName(), true,
COSInteger.class.getClassLoader());
thread.join();
}
}
{code}
I was able to reproduce in 2.0.5 with a few executions.
I downloaded 3.0.0-SNAPSHOT 453 and ran the test against it and I can no longer
reproduce the issue.
Would you mind removing 2.0.5 from the fix version list? It tricked me into
attempting that first which didn't work out.
> Static Initialization Deadlock between COSNumber/COSInteger
> -----------------------------------------------------------
>
> Key: PDFBOX-3698
> URL: https://issues.apache.org/jira/browse/PDFBOX-3698
> Project: PDFBox
> Issue Type: Bug
> Affects Versions: 2.0.3
> Environment: Mac OSX 10.12.3, Java(TM) SE Runtime Environment (build
> 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
> Reporter: Sean Story
> Assignee: Tilman Hausherr
> Priority: Major
> Fix For: 2.0.5, 3.0.0 PDFBox
>
>
> h3. Problem
> Using Tika 1.10 (PDF Box 1.8.10) to parse PDF documents in a multi-threaded
> application, processing unexpectedly halted. Investigating the output of a
> {{kill -3}}, we found:
> {noformat}
> "pool-2-thread-18" #50 prio=5 os_prio=0 tid=0x00002af088a67000 nid=0xc9b9 in
> Object.wait() [0x00002af0dc803000]
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.pdfbox.pdfparser.BaseParser.parseDirObject(BaseParser.java:1348)
> x 15
> "pool-2-thread-13" #45 prio=5 os_prio=0 tid=0x00002af0cf910800 nid=0xc9b4 in
> Object.wait() [0x00002af0dc2ff000]
> java.lang.Thread.State: RUNNABLE
> at org.apache.pdfbox.cos.COSDocument.getObjectFromPool(COSDocument.java:720)
> at org.apache.pdfbox.pdfparser.PDFParser.parseObject(PDFParser.java:685)
> x 2
> "pool-2-thread-11" #43 prio=5 os_prio=0 tid=0x00002af0cfba6000 nid=0xc9b2 in
> Object.wait() [0x00002af0dc0fc000]
> java.lang.Thread.State: RUNNABLE
> at org.apache.pdfbox.cos.COSNumber.<clinit>(COSNumber.java:33)
> at
> org.apache.pdfbox.pdfparser.BaseParser.parseDirObject(BaseParser.java:1348)
> x 1
> {noformat}
> Upon further investigation, it appears that there is a risk for deadlock when
> BaseParser calls {{COSNumber.get()}} and COSDocument call
> {{COSInteger.get()}}.
> I was able to semi-reliably replicate this issue with the below Spock test:
> {noformat}
> import org.apache.pdfbox.cos.COSInteger
> import org.apache.pdfbox.cos.COSNumber
> import spock.lang.Specification
> class ThreadingIssueSpec extends Specification{
> def "testy test"(){
> setup:
> Thread thread = new Thread(new Runnable(){
> @Override
> void run() {
> for (int i =0; i<100; i++){
> COSNumber.get("-")
> }
> }
> })
> thread.start()
> for(int i =0; i<100; i++) {
> COSInteger.get("-")
> }
> thread.join()
> expect:
> 1==1
> }
> }
> {noformat}
> (you'll likely need to run this several times before the test hangs, but it
> does eventually hang)
> I updated my Tika dep to 1.14 (PDF Box 2.0.3) and was still able to replicate
> this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
