Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: current
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      Description

      Problem with rendering file from http://www.ikea.com/ms/cs_CZ/pdf/externi_sklad.pdf (also attached).
      JVM just crash on Linux without any exception, message, etc. On Mac OS X I received "Invalid access of stack red zone 0x10b012fe8 rip=0x11fd4785f" and JVM also crashed with Apple crash report window appeared.

      Code used:
      int thumbSize = 128;
      byte[] file = // binary copy of upper file from FileInputStream

      PDFFile pdffile = new PDFFile(ByteBuffer.wrap(file));

      PDFPage page = pdffile.getPage(0);

      Rectangle2D box = page.getBBox();

      Rectangle rect = new Rectangle(0, 0, (int) box.getWidth(),
      (int) box.getHeight());

      double ratio = box.getWidth() / box.getHeight();

      int h = thumbSize;
      int w = thumbSize;

      int t = 0;
      int l = 0;

      if (ratio > 1)

      { h = (int) (thumbSize / ratio); t = (thumbSize - h) / 2; }

      else

      { w = (int) (thumbSize * ratio); l = (thumbSize - w) / 2; }

      Image img = page.getImage(w, h, rect, null, true, true);

        Activity

        Hide
        lujke added a comment -

        If you run your program in a working directory that you have write permissions on a hs_err_pid<#>.log file should be generated which will contain more detailed information which you should attach here. For my part, I could generate this PDF fine with 1.6 JVMs on 32 bit Windows Vista. I did, however, get a crash running under 1.5, which is most likely related to a JVM bug.

        The problem will be clearer once you supply the hotspot log file as described above, but it's extremely likely that the root problem is a JVM bug. The path being drawn when my 1.5 JDK crashed, though, has quite a number of points, so maybe you'll find that just upping the stack size with -Xss will help. Smaller stack overhead for 32-bit machines may have prevented the bug from occurring in my setup. If it does end up being something to do with a JVM bug related to long paths being drawn then we might be able to work around it by drawing only parts of a path at a time.

        Show
        lujke added a comment - If you run your program in a working directory that you have write permissions on a hs_err_pid<#>.log file should be generated which will contain more detailed information which you should attach here. For my part, I could generate this PDF fine with 1.6 JVMs on 32 bit Windows Vista. I did, however, get a crash running under 1.5, which is most likely related to a JVM bug. The problem will be clearer once you supply the hotspot log file as described above, but it's extremely likely that the root problem is a JVM bug. The path being drawn when my 1.5 JDK crashed, though, has quite a number of points, so maybe you'll find that just upping the stack size with -Xss will help. Smaller stack overhead for 32-bit machines may have prevented the bug from occurring in my setup. If it does end up being something to do with a JVM bug related to long paths being drawn then we might be able to work around it by drawing only parts of a path at a time.
        Hide
        cecilia.bernardi added a comment -

        Same problem.
        CentOS 64bit, Java(TM) SE Runtime Environment (build 1.6.0_26-b03).

        I've solved as follows:

        in class com.sun.pdfview.PDFRenderer

        I've modified method autoAdjustStrokeWidth in this way:

        private BasicStroke autoAdjustStrokeWidth(Graphics2D g, BasicStroke bs) {
        AffineTransform bt = new AffineTransform(g.getTransform());
        float width = bs.getLineWidth() * (float) bt.getScaleX();
        BasicStroke stroke = bs;
        if (width < 1f) {
        if (bt.getScaleX() > 0.01)

        { width = 1.0f / (float) bt.getScaleX(); }

        else

        { // prevent division by a really small number width = 1.0f; }

        }
        stroke = new BasicStroke(width,
        bs.getEndCap(),
        bs.getLineJoin(),
        bs.getMiterLimit(),
        getDashArray(bs),
        bs.getDashPhase());

        return stroke;
        }

        And added this method:

        private float[] getDashArray(BasicStroke bs) {
        float[] dashArray = bs.getDashArray();

        if (dashArray != null) {
        int arrayLength = dashArray.length;
        float dash;
        for (int i = 0; i<arrayLength; i++) {
        dash = dashArray[i];
        if (dash == 1.0E-5f)

        { dashArray[i] = 0.01f; }

        }
        }
        return dashArray;
        }

        This fix works also for file attached in this issue.

        I don't know if this helps, If needed I can provide source and test.

        Best Regards, Cecilia

        Show
        cecilia.bernardi added a comment - Same problem. CentOS 64bit, Java(TM) SE Runtime Environment (build 1.6.0_26-b03). I've solved as follows: in class com.sun.pdfview.PDFRenderer I've modified method autoAdjustStrokeWidth in this way: private BasicStroke autoAdjustStrokeWidth(Graphics2D g, BasicStroke bs) { AffineTransform bt = new AffineTransform(g.getTransform()); float width = bs.getLineWidth() * (float) bt.getScaleX(); BasicStroke stroke = bs; if (width < 1f) { if (bt.getScaleX() > 0.01) { width = 1.0f / (float) bt.getScaleX(); } else { // prevent division by a really small number width = 1.0f; } } stroke = new BasicStroke(width, bs.getEndCap(), bs.getLineJoin(), bs.getMiterLimit(), getDashArray(bs), bs.getDashPhase()); return stroke; } And added this method: private float[] getDashArray(BasicStroke bs) { float[] dashArray = bs.getDashArray(); if (dashArray != null) { int arrayLength = dashArray.length; float dash; for (int i = 0; i<arrayLength; i++) { dash = dashArray [i] ; if (dash == 1.0E-5f) { dashArray[i] = 0.01f; } } } return dashArray; } This fix works also for file attached in this issue. I don't know if this helps, If needed I can provide source and test. Best Regards, Cecilia

          People

          • Assignee:
            Unassigned
            Reporter:
            vkweb
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: