ICEpdf
  1. ICEpdf
  2. PDF-42

Hang when disposing of document

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0
    • Fix Version/s: 3.1
    • Component/s: Core/Parsing
    • Labels:
      None
    • Environment:
      -

      Description

      I had a hang just now on disposal of a Document. Because ICEpdf is taking up the event dispatch thread, the application can no longer be used. On the screen where this happened, multiple PDF documents are opened one after another, one at a time. The disposal may have occurred while the document was still being loaded, or while it was rendering.

      I got this error on stderr which might be related:

      java.lang.ArrayIndexOutOfBoundsException: 2
      at org.icepdf.core.pobjects.filters.CCITTFax.addRun(Unknown Source)
      at org.icepdf.core.pobjects.filters.CCITTFax.resetRuns(Unknown Source)
      at org.icepdf.core.pobjects.filters.CCITTFax.Group4Decode(Unknown Source)
      at org.icepdf.core.pobjects.Stream.ccittfaxDecode(Unknown Source)
      at org.icepdf.core.pobjects.Stream.decodeCCITTFaxDecodeOrDCTDecodeImage(Unknown Source)
      at org.icepdf.core.pobjects.Stream.getImage(Unknown Source)
      .....

      Reproducing the issue requires opening and closing dozens of PDF files relatively quickly and frequently, in order to get an interrupt during the PDF engine initialising or rendering.

      This is what we're actually doing:

      @Override
      public Image getPageImage(int pageNumber, float zoomLevel, ImageObserver observer)
      {
      // Library limitation, we can only pass in a fixed zoom for both X and Y.
      float actualZoom = (float) (zoomLevel / unitsToScreen.getScaleX());

      // ICEpdf doesn't support ImageObserver for incremental painting.
      // In some respects this is good as it means one less thread hanging around doing stuff
      // in the background, but we do lose the functionality of Sun's pdfrenderer which would
      // display very quickly and then paint the page in a background thread.
      return document.getPageImage(pageNumber - 1,
      GraphicsRenderingHints.SCREEN,
      Page.BOUNDARY_CROPBOX,
      0.0f, // rotation
      actualZoom);
      }

      @Override
      public void close()
      {
      document.dispose();
      }

      And it's the dispose() which for some reason deadlocks.
      at org.icepdf.core.pobjects.Stream.getImage(Unknown Source)
      at org.icepdf.core.pobjects.Resources.getImage(Unknown Source)
      at org.icepdf.core.util.ContentParser.parse(Unknown Source)
      at org.icepdf.core.pobjects.Page.init(Unknown Source)
      at org.icepdf.core.pobjects.Page.paint(Unknown Source)

        Activity

        Hide
        Patrick Corless added a comment -

        When working on PDF-13 I was able to reproduce this issue. Basically the deadlock was occurring because a page was trying to be initialized to while it was being disposed. I've added some new synchronization code that should avoid this problem in the future.

        Show
        Patrick Corless added a comment - When working on PDF-13 I was able to reproduce this issue. Basically the deadlock was occurring because a page was trying to be initialized to while it was being disposed. I've added some new synchronization code that should avoid this problem in the future.
        Hide
        Patrick Corless added a comment -

        ICEpdf 3.1.0 has been released, closing issues.

        Show
        Patrick Corless added a comment - ICEpdf 3.1.0 has been released, closing issues.

          People

          • Assignee:
            Patrick Corless
            Reporter:
            Tyler Johnson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: