Uploaded image for project: 'PDFBox'
  1. PDFBox
  2. PDFBOX-1336

JVM Crashes on Linux OS + Sun JVM + PDFBox

Details

    • Bug
    • Status: Closed
    • Critical
    • Resolution: Fixed
    • 1.7.0
    • 2.0.0
    • None
    • None
    • CentOS 5.6
      Sun JVM Java version: 6 update 31
      Tomcat 7.0.26

    Description

      A fatal error has been detected by the Java Runtime Environment:
      #

      1. SIGSEGV (0xb) at pc=0x796af64d, pid=16603, tid=2021653392
        #
      2. JRE version: 6.0_31-b04
      3. Java VM: Java HotSpot(TM) Server VM (20.6-b01 mixed mode linux-x86 )
      4. Problematic frame:
      5. C [libfontmanager.so+0x1e64d] imaginary long double+0x7d
        #
      6. If you would like to submit a bug report, please visit:
      7. http://java.sun.com/webapps/bugreport/crash.jsp
      8. The crash happened outside the Java Virtual Machine in native code.
      9. See problematic frame for where to report the bug.

      I can provide the full error, please let me know.

      Attachments

        1. hs_err_pid16603.log
          69 kB
          Ann Addicks
        2. pdfcrowd_1334685364.pdf
          28 kB
          Josh Brackett
        3. CrashTest.java
          1 kB
          Josh Brackett

        Issue Links

          Activity

            ann.addicks Ann Addicks added a comment -

            Full crash log

            ann.addicks Ann Addicks added a comment - Full crash log
            tboehme Timo Boehme added a comment -

            As you can see from the crash log the error occurs in a native library called by the Java VM. The library is supposed to handle font data. Thus the font library shipped with your OS seems to have a bug or the font data is corrupted and the library cannot cope with it. Thus I don't think there is something we can do at PDFBOX side. If you can share the problematic document we could test if this problem occurs with other environments as well.

            tboehme Timo Boehme added a comment - As you can see from the crash log the error occurs in a native library called by the Java VM. The library is supposed to handle font data. Thus the font library shipped with your OS seems to have a bug or the font data is corrupted and the library cannot cope with it. Thus I don't think there is something we can do at PDFBOX side. If you can share the problematic document we could test if this problem occurs with other environments as well.
            jbrackett Josh Brackett added a comment - - edited

            Added PDF displaying the issue.

            In our testing the problem occurs on both Linux and Windows but not on Mac.

            Using an openjdk version of the jvm resolves the crash problem but the font is not correct and some characters are not displayed correctly.

            Using the latest 1.6 jdk available for the Mac results in the best representation of the pdf in question.

            java version "1.6.0_31"
            Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635)
            Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)

            jbrackett Josh Brackett added a comment - - edited Added PDF displaying the issue. In our testing the problem occurs on both Linux and Windows but not on Mac. Using an openjdk version of the jvm resolves the crash problem but the font is not correct and some characters are not displayed correctly. Using the latest 1.6 jdk available for the Mac results in the best representation of the pdf in question. java version "1.6.0_31" Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)
            tboehme Timo Boehme added a comment -

            I can confirm this on Linux with 1.6. This should be reported to Oracle as a bug in libfontmanager library which is shipped with Java. There is already a similar report in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6962367 but this seems to be another one.

            tboehme Timo Boehme added a comment - I can confirm this on Linux with 1.6. This should be reported to Oracle as a bug in libfontmanager library which is shipped with Java. There is already a similar report in http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6962367 but this seems to be another one.
            tboehme Timo Boehme added a comment -

            This maybe also relates to Java bugs closed with current version. See https://bugzilla.redhat.com/show_bug.cgi?id=829361#c0

            tboehme Timo Boehme added a comment - This maybe also relates to Java bugs closed with current version. See https://bugzilla.redhat.com/show_bug.cgi?id=829361#c0
            ann.addicks Ann Addicks added a comment -

            It continues to crash in update 33, I'll post in Oracle's defect tracker. Thank you, Timo, for looking into this!

            ann.addicks Ann Addicks added a comment - It continues to crash in update 33, I'll post in Oracle's defect tracker. Thank you, Timo, for looking into this!

            The used fonts are the problem. Those embedded subsets of true type fonts are not wellformed concerning the ttf specs. In most cases the JVM font manager just throws an exception, but this one leads to a crash.
            The goal of PDFBOX-490 is not to use the fontmager anymore.

            lehmi Andreas LehmkĂĽhler added a comment - The used fonts are the problem. Those embedded subsets of true type fonts are not wellformed concerning the ttf specs. In most cases the JVM font manager just throws an exception, but this one leads to a crash. The goal of PDFBOX-490 is not to use the fontmager anymore.
            jbrackett Josh Brackett added a comment - Oracle Java bug for reference: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7176622
            ck@newsclub.de Christian KohlschĂĽtter added a comment - - edited

            I guess PDFBOX-1580 fixes the crash.

            ck@newsclub.de Christian KohlschĂĽtter added a comment - - edited I guess PDFBOX-1580 fixes the crash.
            tchojecki Thomas Chojecki added a comment - This issue should be fixed with PDFBOX-1580 . Thx to Christian KohlschĂĽtter for the patch. Can not reproduce it. Can someone test it with the given snapshot? http://people.apache.org/~tchojecki/PDFBOX-1580/pdfbox-2.0.0-SNAPSHOT.jar http://people.apache.org/~tchojecki/PDFBOX-1580/fontbox-2.0.0-SNAPSHOT.jar http://people.apache.org/~tchojecki/PDFBOX-1580/jempbox-2.0.0-SNAPSHOT.jar
            jbrackett Josh Brackett added a comment - - edited

            Hey Thomas, with those snapshots it's still crashing for me although the error coming from the JVM is a little different, but that may just be because we're running 7 now.

            #

            1. A fatal error has been detected by the Java Runtime Environment:
              #
            2. SIGSEGV (0xb) at pc=0x0000000160d1bc04, pid=836, tid=27395
              #
            3. JRE version: 7.0_17-b02
            4. Java VM: Java HotSpot(TM) 64-Bit Server VM (23.7-b01 mixed mode bsd-amd64 compressed oops)
            5. Problematic frame:
            6. C [libt2k.dylib+0x18c04] Compute_cmapClass_GlyphIndex+0x5
              #

            Edit:
            Using version 1.8.1 results in the same error.

            jbrackett Josh Brackett added a comment - - edited Hey Thomas, with those snapshots it's still crashing for me although the error coming from the JVM is a little different, but that may just be because we're running 7 now. # A fatal error has been detected by the Java Runtime Environment: # SIGSEGV (0xb) at pc=0x0000000160d1bc04, pid=836, tid=27395 # JRE version: 7.0_17-b02 Java VM: Java HotSpot(TM) 64-Bit Server VM (23.7-b01 mixed mode bsd-amd64 compressed oops) Problematic frame: C [libt2k.dylib+0x18c04] Compute_cmapClass_GlyphIndex+0x5 # Edit: Using version 1.8.1 results in the same error.
            jbrackett Josh Brackett added a comment -

            Test case to use with previously attached pdf that causes jvm to crash.

            jbrackett Josh Brackett added a comment - Test case to use with previously attached pdf that causes jvm to crash.
            ck@newsclub.de Christian KohlschĂĽtter added a comment - - edited

            I can confirm that the snapshot provided by Thomas does not fix the bug.

            I think the snapshot simply does not contain the patch, as I cannot see a reference to canDisplay in PDType0Font.class.

            Applying the patch of PDFBOX-1580 directly to the source file, then recompiling it, fixes the crash in the testcase provided by Josh, at least for me here.

            ck@newsclub.de Christian KohlschĂĽtter added a comment - - edited I can confirm that the snapshot provided by Thomas does not fix the bug. I think the snapshot simply does not contain the patch, as I cannot see a reference to canDisplay in PDType0Font.class. Applying the patch of PDFBOX-1580 directly to the source file, then recompiling it, fixes the crash in the testcase provided by Josh, at least for me here.

            I checked the provided jar file with a decompiler and you are right. I commented it out to test it and forget to undo my changes before building. I have uploaded an up to date jar, after a check it has the needed line.
            http://people.apache.org/~tchojecki/PDFBOX-1580/pdfbox-2.0.0-SNAPSHOT_fix.jar

            So if someone can confirm that this work, I would close both issues.

            tchojecki Thomas Chojecki added a comment - I checked the provided jar file with a decompiler and you are right. I commented it out to test it and forget to undo my changes before building. I have uploaded an up to date jar, after a check it has the needed line. http://people.apache.org/~tchojecki/PDFBOX-1580/pdfbox-2.0.0-SNAPSHOT_fix.jar So if someone can confirm that this work, I would close both issues.

            Please wait before closing this issue to early. I've the impression that the fix doesn't really solve the issue. It is the JVM you are using to run PDFBox. There are combinations which are working with AND without the proposed fix depending on the used environment.

            If have a solution at least for the Delta-pdf attached to PDFBOX-1426, maybe that will fix some of the others too.

            lehmi Andreas LehmkĂĽhler added a comment - Please wait before closing this issue to early. I've the impression that the fix doesn't really solve the issue. It is the JVM you are using to run PDFBox. There are combinations which are working with AND without the proposed fix depending on the used environment. If have a solution at least for the Delta-pdf attached to PDFBOX-1426 , maybe that will fix some of the others too.

            I ran some tests a can confirm that the fix works. My "solution" was a misunderstanding. I thought I found a fix but in the end my code simply substituted the problematic font so that it didn't trigger the crash.
            The fix also works for PDFBOX-1426.

            lehmi Andreas LehmkĂĽhler added a comment - I ran some tests a can confirm that the fix works. My "solution" was a misunderstanding. I thought I found a fix but in the end my code simply substituted the problematic font so that it didn't trigger the crash. The fix also works for PDFBOX-1426 .

            Just to avoid misunderstandings, the JVM doesn't crash anymore but the pdfs aren't rendered correct. But that's another issue

            lehmi Andreas LehmkĂĽhler added a comment - Just to avoid misunderstandings, the JVM doesn't crash anymore but the pdfs aren't rendered correct. But that's another issue
            jbrackett Josh Brackett added a comment -

            Would you guys consider putting this in the 1.8.2 release or is that too far along?

            jbrackett Josh Brackett added a comment - Would you guys consider putting this in the 1.8.2 release or is that too far along?

            We don't have any plans for a new 1.8.x release, but if there will be one PDFBOX-1580 will be part of it. I already changed the fix version

            lehmi Andreas LehmkĂĽhler added a comment - We don't have any plans for a new 1.8.x release, but if there will be one PDFBOX-1580 will be part of it. I already changed the fix version
            shalom938 Shalom Ben-Zvi added a comment -

            I got passed this error by upgrading to 1.8.2. i had it happening consistently with a certain document.
            but now I'm getting this error on another document and the jvm dies :
            java: ../../../src/share/native/sun/font/t2k/t1.c:1936: DecryptData: Assertion `byteCount == 0' failed.

            I could not find any clue to this error in google.

            it happens with that code:
            List<PDPage> pages = pdDocument.getDocumentCatalog().getAllPages();
            for(PDPage page: pages){
            BufferedImage image = page.convertToImage(BufferedImage.TYPE_INT_RGB, 112);
            }

            it is sometimes preceded with messages like this:
            2013-07-25 18:19:15,264 | 061eacb4-9980-4309-960f-3412825eb02e | INFO | wecaCjpegAsyncExecutor-5 | PDType1Font | Can't read the embedded type1 font EJRZTM+CMBX12
            2013-07-25 18:19:15,267 | 061eacb4-9980-4309-960f-3412825eb02e | INFO | wecaCjpegAsyncExecutor-5 | PDType1Font | Can't find the specified font EJRZTM+CMBX12
            2013-07-25 18:19:15,268 | 061eacb4-9980-4309-960f-3412825eb02e | INFO | wecaCjpegAsyncExecutor-5 | PDType1Font | Using font SansSerif.plain instead
            2013-07-25 18:19:15,279 | 061eacb4-9980-4309-960f-3412825eb02e | INFO | wecaCjpegAsyncExecutor-4 | PDType1Font | Can't read the embedded type1 font EJRZTM+CMBX12
            2013-07-25 18:19:15,290 | 061eacb4-9980-4309-960f-3412825eb02e | INFO | wecaCjpegAsyncExecutor-4 | PDType1Font | Can't find the specified font EJRZTM+CMBX12
            2013-07-25 18:19:15,296 | 061eacb4-9980-4309-960f-3412825eb02e | INFO | wecaCjpegAsyncExecutor-4 | PDType1Font | Using font SansSerif.plain instead

            shalom938 Shalom Ben-Zvi added a comment - I got passed this error by upgrading to 1.8.2. i had it happening consistently with a certain document. but now I'm getting this error on another document and the jvm dies : java: ../../../src/share/native/sun/font/t2k/t1.c:1936: DecryptData: Assertion `byteCount == 0' failed. I could not find any clue to this error in google. it happens with that code: List<PDPage> pages = pdDocument.getDocumentCatalog().getAllPages(); for(PDPage page: pages){ BufferedImage image = page.convertToImage(BufferedImage.TYPE_INT_RGB, 112); } it is sometimes preceded with messages like this: 2013-07-25 18:19:15,264 | 061eacb4-9980-4309-960f-3412825eb02e | INFO | wecaCjpegAsyncExecutor-5 | PDType1Font | Can't read the embedded type1 font EJRZTM+CMBX12 2013-07-25 18:19:15,267 | 061eacb4-9980-4309-960f-3412825eb02e | INFO | wecaCjpegAsyncExecutor-5 | PDType1Font | Can't find the specified font EJRZTM+CMBX12 2013-07-25 18:19:15,268 | 061eacb4-9980-4309-960f-3412825eb02e | INFO | wecaCjpegAsyncExecutor-5 | PDType1Font | Using font SansSerif.plain instead 2013-07-25 18:19:15,279 | 061eacb4-9980-4309-960f-3412825eb02e | INFO | wecaCjpegAsyncExecutor-4 | PDType1Font | Can't read the embedded type1 font EJRZTM+CMBX12 2013-07-25 18:19:15,290 | 061eacb4-9980-4309-960f-3412825eb02e | INFO | wecaCjpegAsyncExecutor-4 | PDType1Font | Can't find the specified font EJRZTM+CMBX12 2013-07-25 18:19:15,296 | 061eacb4-9980-4309-960f-3412825eb02e | INFO | wecaCjpegAsyncExecutor-4 | PDType1Font | Using font SansSerif.plain instead

            It looks good after solving PDFBOX-490 and I'm sure there won't be crashes anymore as PDFBox don't rely on the JDK anymore when rendering TTF fonts.

            lehmi Andreas LehmkĂĽhler added a comment - It looks good after solving PDFBOX-490 and I'm sure there won't be crashes anymore as PDFBox don't rely on the JDK anymore when rendering TTF fonts.

            People

              lehmi Andreas LehmkĂĽhler
              ann.addicks Ann Addicks
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: