ICEpdf
  1. ICEpdf
  2. PDF-1337

Document.setByteArray(byte[], int, int, String) throws IOException without a message when used in a loop

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 6.3.2
    • Fix Version/s: None
    • Component/s: Core/Parsing
    • Labels:
      None
    • Environment:
      Windows 7, Oracle JDK 8u60

      Description

      This is related to [PDF-1336].

      I have a process which regularly loads different PDF files using ICEpdf call Document.setByteArray(byte[], int, int, String).

      Today I observed a situation, when there are many PDF documents to load and many of them cause the issue described in [PDF-1336]. But this time I noticed that the stack trace for some PDF files is a little bit different from the one in [PDF-1336], because it does not contain message for the exception:

      ============================================
      java.io.IOException
          at org.icepdf.core.pobjects.Document.setInputStream(Document.java:499)
          at org.icepdf.core.pobjects.Document.setByteArray(Document.java:365)
          at com.example.App.testPdf(App.java:11)
          ...
      ============================================


      And in this case the following appears in standard error output stream:

      ============================================
      Dec 18, 2019 2:11:00 AM org.icepdf.core.pobjects.Document setInputStream
      WARNING: Cross reference deferred loading failed, will fall back to linear reading.
      Dec 18, 2019 2:11:00 AM org.icepdf.core.pobjects.Document setInputStream
      SEVERE: Error loading PDF Document.
      java.lang.ClassCastException
      ============================================


      As you can see, there is no stack trace in standard error output stream.


      I tried to reproduce this locally and found out that with my local machine it reproduces if I use more than 30 files from [PDF-1336]. Then I decided to make it even more reproducible. I wrote a for-loop, which tries to load the same PDF file 100 times. This loop ignores any exceptions which contain a message, equal to the message from [PDF-1336]

      ============================================
      String pdfPath = "/full/path/to/pdf/file/wich/causes/PDF-1336.pdf";
      for (int i = 1; i <= 100; i++) {
          try {
              new App().testPdf(pdfPath);
          } catch (Exception e) {
              if (!"java.lang.String cannot be cast to java.lang.Number".equals(e.getMessage())) {
                  throw e;
              }
          }
      }
      ============================================


      With this loop I can reproduce the issue constantly with many files from [PDF-1336]. For example, you can find {{standard_error_stream.txt}} attached (I reduced stack traces for readability), which demonstrates that IOException with empty message was encountered on i=25.

      The implementation of App class is the same as in [PDF-1336]:

      ============================================
      package com.example;

      import org.icepdf.core.pobjects.Document;
      import java.nio.file.Files;
      import java.nio.file.Paths;

      public class App {
          public void testPdf(String pdfPath) throws Exception {
              byte[] bytes = Files.readAllBytes(Paths.get(pdfPath));
              Document document = new Document();
              document.setByteArray(bytes, 0, bytes.length, null);
              document.dispose();
          }
      }
      ============================================


      The only dependency I use is {{icepdf-core-6.3.2.jar}}. And similar to [PDF-1336], this issue seems to be a regression: if I use {{icepdf-core-6.2.2.jar}}, the for-loop does not face with any expections at all.

      I can provide you with PDF files (if needed) via email channel.

        Activity

        Hide
        Yauheni Sidarenka added a comment -

        Looks like the lack of message and stack trace is caused by default behavior of JVM. See section about "cold" built-in exceptions in HotSpot VM release notes: https://www.oracle.com/java/technologies/javase/release-notes-introduction.html#hotspot

        Setting -XX:-OmitStackTraceInFastThrow in JAVA_OPTS should address the issue. I will check it later when I have time.

        Show
        Yauheni Sidarenka added a comment - Looks like the lack of message and stack trace is caused by default behavior of JVM. See section about "cold" built-in exceptions in HotSpot VM release notes: https://www.oracle.com/java/technologies/javase/release-notes-introduction.html#hotspot Setting -XX:-OmitStackTraceInFastThrow in JAVA_OPTS should address the issue. I will check it later when I have time.

          People

          • Assignee:
            Patrick Corless
            Reporter:
            Yauheni Sidarenka
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: