ICEpdf
  1. ICEpdf
  2. PDF-1007

EmptyStackException thrown when rendering PDF

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 6.1.2
          • Fix Version/s: 6.3
          • Component/s: Core/Rendering
          • Labels:
            None
          • Environment:
            All

            Description

            When rendering the provided PDF file the following exceptions are thrown and the content of the PDF is rendered blank:

            WARNING: Fatal error parsing PDF file stream.
            java.util.EmptyStackException
            at java.util.Stack.peek(Stack.java:102)
            at java.util.Stack.pop(Stack.java:84)
            at org.icepdf.core.util.Parser.getObject(Parser.java:144)
            at org.icepdf.core.util.LazyObjectLoader.loadObject(LazyObjectLoader.java:73)
            at org.icepdf.core.util.Library.getObject(Library.java:166)
            at org.icepdf.core.pobjects.PageTree.getPageOrPagesPotentiallyNotInitedFromReferenceAt(PageTree.java:282)
            at org.icepdf.core.pobjects.PageTree.getPagePotentiallyNotInitedByRecursiveIndex(PageTree.java:301)
            at org.icepdf.core.pobjects.PageTree.getPage(PageTree.java:381)
            at org.icepdf.ri.common.views.PageViewComponentImpl.getPage(PageViewComponentImpl.java:336)
            at org.icepdf.ri.common.views.PageViewComponentImpl$DirtyTimerAction.actionPerformed(PageViewComponentImpl.java:1265)
            at javax.swing.Timer.fireActionPerformed(Timer.java:312)
            at javax.swing.Timer$DoPostEvent.run(Timer.java:244)
            at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:312)
            at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:733)
            at java.awt.EventQueue.access$200(EventQueue.java:103)
            at java.awt.EventQueue$3.run(EventQueue.java:694)
            at java.awt.EventQueue$3.run(EventQueue.java:692)
            at java.security.AccessController.doPrivileged(Native Method)
            at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
            at java.awt.EventQueue.dispatchEvent(EventQueue.java:703)
            at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
            at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
            at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
            at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
            at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

              Issue Links

              is duplicated by

              Bug - A problem which impairs or prevents the functions of the product. PDF-1187 Document with corrupt xref table intermittently fails to load

              • Major - Major loss of function.
              • Closed

              Improvement - An improvement or enhancement to an existing feature or task. PDF-869 Improving xref offset correction

              • Major - Major loss of function.
              • Closed

                Activity

                Ascending order - Click to sort in descending order
                Hide
                Permalink
                Patrick Corless added a comment -

                I would appear the the file byte offset aren't correct which is making it impossible for our object parser to find the key objects in the file. Acrobat adjusts for the error and will correct the error when the file is saved.

                Quite a bit of work is needed to fix this on our end as we'll need to create a object indexer and potentially correct the file. Can you find out if this is a one off or if they have a lot of files touched by the PDF producer "Generated by: AquaPDF 3.0.5 http://aquapdf.com".

                Show
                Patrick Corless added a comment - I would appear the the file byte offset aren't correct which is making it impossible for our object parser to find the key objects in the file. Acrobat adjusts for the error and will correct the error when the file is saved. Quite a bit of work is needed to fix this on our end as we'll need to create a object indexer and potentially correct the file. Can you find out if this is a one off or if they have a lot of files touched by the PDF producer "Generated by: AquaPDF 3.0.5 http://aquapdf.com ".
                Hide
                Permalink
                Arran Mccullough added a comment -

                I have heard back from the client and they aren't able to tell how many of their PDF files have been touched by that PDF producer.

                Show
                Arran Mccullough added a comment - I have heard back from the client and they aren't able to tell how many of their PDF files have been touched by that PDF producer.
                Hide
                Permalink
                Patrick Corless added a comment -

                The file in question is quite strange as it actually made up of two documents. The first seems to be of 4 pages and the later revision is 6 pages. Normally this sort of change would be done as an incremental updates but that is neither here nor there.

                As mentioned the document(s) don't have valid xref entry which makes this a special case. When a xref table is deemed incorrect we fall back to a linear read of the file and rebuild the xref offsets. This methods uses our home grown BufferedMarkedInputStream so we can keep track of the the current location in the file. What eventually was discovered was the that when we moved accross the 8K buffer boundary we would loose one byte in our count, 16K then two btyes and so on. As a result we have a new xref table with slightly incorrect offset values.

                The effects of the drift are quite interesting as they manifest in very different ways depending on how our object cache is garbage collected. When reparsing say object 26 0 obj the one byte drift could result in the object being stored as object 6 which is incorrect. There are lots of similar cases.

                Show
                Patrick Corless added a comment - The file in question is quite strange as it actually made up of two documents. The first seems to be of 4 pages and the later revision is 6 pages. Normally this sort of change would be done as an incremental updates but that is neither here nor there. As mentioned the document(s) don't have valid xref entry which makes this a special case. When a xref table is deemed incorrect we fall back to a linear read of the file and rebuild the xref offsets. This methods uses our home grown BufferedMarkedInputStream so we can keep track of the the current location in the file. What eventually was discovered was the that when we moved accross the 8K buffer boundary we would loose one byte in our count, 16K then two btyes and so on. As a result we have a new xref table with slightly incorrect offset values. The effects of the drift are quite interesting as they manifest in very different ways depending on how our object cache is garbage collected. When reparsing say object 26 0 obj the one byte drift could result in the object being stored as object 6 which is incorrect. There are lots of similar cases.
                Hide
                Permalink
                Patrick Corless added a comment -

                Marking as fixed.

                Show
                Patrick Corless added a comment - Marking as fixed.

                  People

                  • Assignee:
                    Patrick Corless
                    Reporter:
                    Arran Mccullough
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    2 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: