[
https://issues.apache.org/jira/browse/PDFBOX-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Larry West updated PDFBOX-845:
------------------------------
Attachment: pddocument-load-lockup.stack
This is the output of "jstack -l", with the names of our routines (that call
PDDocument.load(File) excised.
> Lockup in PDDocument.load() --> PDFParser.parseObject() with 6 threads
> ----------------------------------------------------------------------
>
> Key: PDFBOX-845
> URL: https://issues.apache.org/jira/browse/PDFBOX-845
> Project: PDFBox
> Issue Type: Bug
> Components: Parsing
> Affects Versions: 1.2.1
> Environment: Linux lxdev01 2.6.32-24-generic #42-Ubuntu SMP Fri Aug
> 20 14:24:04 UTC 2010 i686 GNU/Linux
> java version "1.6.0_20"
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
> Java HotSpot(TM) Server VM (build 16.3-b01, mixed mode)
> testng 5.11
> running under maven-surefire plugin v2.5 with parallel=methods and
> threadCount=6
> Reporter: Larry West
> Priority: Critical
> Attachments: pddocument-load-lockup.stack
>
> Original Estimate: 32h
> Remaining Estimate: 32h
>
> This is a TestNG unit test suite, with each test loading a different PDF via
> PDDocument.load(). I just switched TestNG to parallel=methods (had been
> serial) and it locked up first time. "jstack -l" output will be attached,
> but I'm putting the pdfbox portions here (just below).
> In looking at the code, it's not clear what's being waited on, except that
> four of the threads are stuck in BaseParser.parseDirObject(), apparently
> waiting on the (synchronized) toString() method of a [local] StringBuffer.
> (StringBuffer is used in BaseParser.java where a StringBuilder is clearly
> preferable -- this is probably true for every local instance of a
> StringBuffer.)
> I don't know why that would cause the thread to sit waiting, though (JVM
> problem? 1.6.0_20 on Linux), and the other two threads appear to be waiting
> on COSObjectKey.getNumber() [perhaps], and I see no synchronized objects or
> methods there.
> Finding the cause of the lockup would be preferable, but replacing
> StringBuffer with StringBuilder whereever they are used locally (possibly
> including any private non-static members) would be an improvement in
> performance if nothing else.
> Threads 1, 2, 4, & 6:
> at
> org.apache.pdfbox.pdfparser.BaseParser.parseDirObject(BaseParser.java:1013)
> at
> org.apache.pdfbox.pdfparser.BaseParser.parseCOSDictionaryValue(BaseParser.java:157)
> at
> org.apache.pdfbox.pdfparser.BaseParser.parseCOSDictionary(BaseParser.java:233)
> at
> org.apache.pdfbox.pdfparser.BaseParser.parseDirObject(BaseParser.java:929)
> at org.apache.pdfbox.pdfparser.PDFParser.parseObject(PDFParser.java:519)
> at org.apache.pdfbox.pdfparser.PDFParser.parse(PDFParser.java:179)
> Threads 3 & 5:
> at
> org.apache.pdfbox.cos.COSDocument.getObjectFromPool(COSDocument.java:481)
> at org.apache.pdfbox.pdfparser.PDFParser.parseObject(PDFParser.java:540)
> at org.apache.pdfbox.pdfparser.PDFParser.parse(PDFParser.java:179)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
