Fop
  1. Fop
  2. FOP-1610

Thread-safety issue rendering SVG

    Details

    • External issue ID:
      46360

      Description

      FOP reuses/caches SVG documents to improve performance. But as we had to learn, this approach is not thread-safe as Batik attaches some facilities (like the CSS engine) to the DOM which are not thread-safe. The detailed discussion of the issue can be found here:
      http://markmail.org/message/2dk2ib4e5t6vfsrl

      The safest approach is to clone the SVG DOM prior to passing it to Batik.

      Obviously that will cost a bit of performance and increase memory usage a bit. If we're careful and have the resources to implement that we can improve performance by caching Batik's GVT tree. Ideas can also be found in the thread indicated above.

        Activity

        Hide
        Jeremias Maerki added a comment -

        Issue fixed as discussed on batik-users.
        http://svn.apache.org/viewvc?rev=724163&view=rev
        http://svn.apache.org/viewvc?rev=724164&view=rev

        I'll keep this open for a bit since I'll have to do the same in the IF branch.

        Show
        Jeremias Maerki added a comment - Issue fixed as discussed on batik-users. http://svn.apache.org/viewvc?rev=724163&view=rev http://svn.apache.org/viewvc?rev=724164&view=rev I'll keep this open for a bit since I'll have to do the same in the IF branch.
        Hide
        Jeremias Maerki added a comment -

        One more note to self: Need to introduce a flag to indicate whether we're working off a potentially cached SVG DOM or off a DOM that comes from an fo:instream-foreign-object in which the cloning is unnecessary.

        Show
        Jeremias Maerki added a comment - One more note to self: Need to introduce a flag to indicate whether we're working off a potentially cached SVG DOM or off a DOM that comes from an fo:instream-foreign-object in which the cloning is unnecessary.
        Hide
        M.H. added a comment -

        I got a NullPointerException during FOP processing while do transformations were processing concurrently. Both include (the same) SVG image files.

        -----------------
        The attribute "style" represents an invalid CSS declaration ("fill:#ef7b00; fill-rule:nonzero; stroke:none; stroke-width:1; stroke-linecap:butt; stroke-linejoin:miter; stroke-dasharray:none;").
        Original message:
        java.lang.NullPointerException
        org.w3c.dom.DOMException: file:/C:/Programme/ddf/xml/images/V10271.svg:
        The attribute "style" represents an invalid CSS declaration ("fill:#ef7b00; fill-rule:nonzero; stroke:none; stroke-width:1; stroke-linecap:butt; stroke-linejoin:miter; stroke-dasharray:none;").
        Original message:
        java.lang.NullPointerException
        at org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(Unknown Source)
        at org.apache.batik.css.engine.CSSEngine.getComputedStyle(Unknown Source)
        at org.apache.batik.bridge.CSSUtilities.getComputedStyle(Unknown Source)
        at org.apache.batik.bridge.CSSUtilities.convertDisplay(Unknown Source)
        at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
        at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source)
        at org.apache.batik.bridge.GVTBuilder.build(Unknown Source)
        at org.apache.fop.render.pdf.PDFSVGHandler.renderSVGDocument(PDFSVGHandler.java:188)

        ---------------------------------------

        see https://issues.apache.org/bugzilla/show_bug.cgi?id=46418

        I guess, there are more threading issues with Batik SVG...

        Show
        M.H. added a comment - I got a NullPointerException during FOP processing while do transformations were processing concurrently. Both include (the same) SVG image files. ----------------- The attribute "style" represents an invalid CSS declaration ("fill:#ef7b00; fill-rule:nonzero; stroke:none; stroke-width:1; stroke-linecap:butt; stroke-linejoin:miter; stroke-dasharray:none;"). Original message: java.lang.NullPointerException org.w3c.dom.DOMException: file:/C:/Programme/ddf/xml/images/V10271.svg: The attribute "style" represents an invalid CSS declaration ("fill:#ef7b00; fill-rule:nonzero; stroke:none; stroke-width:1; stroke-linecap:butt; stroke-linejoin:miter; stroke-dasharray:none;"). Original message: java.lang.NullPointerException at org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(Unknown Source) at org.apache.batik.css.engine.CSSEngine.getComputedStyle(Unknown Source) at org.apache.batik.bridge.CSSUtilities.getComputedStyle(Unknown Source) at org.apache.batik.bridge.CSSUtilities.convertDisplay(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source) at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source) at org.apache.batik.bridge.GVTBuilder.build(Unknown Source) at org.apache.fop.render.pdf.PDFSVGHandler.renderSVGDocument(PDFSVGHandler.java:188) --------------------------------------- see https://issues.apache.org/bugzilla/show_bug.cgi?id=46418 I guess, there are more threading issues with Batik SVG...
        Hide
        Jeremias Maerki added a comment -

        A similar bug has been fixed in FOP Trunk as is noted in this bug. Does this error occur with the current FOP Trunk?

        (In reply to comment #3)
        > I got a NullPointerException during FOP processing while do transformations
        > were processing concurrently. Both include (the same) SVG image files.
        >
        > -----------------
        > The attribute "style" represents an invalid CSS declaration ("fill:#ef7b00;
        > fill-rule:nonzero; stroke:none; stroke-width:1; stroke-linecap:butt;
        > stroke-linejoin:miter; stroke-dasharray:none;").
        > Original message:
        > java.lang.NullPointerException
        > org.w3c.dom.DOMException: file:/C:/Programme/ddf/xml/images/V10271.svg:
        > The attribute "style" represents an invalid CSS declaration ("fill:#ef7b00;
        > fill-rule:nonzero; stroke:none; stroke-width:1; stroke-linecap:butt;
        > stroke-linejoin:miter; stroke-dasharray:none;").
        > Original message:
        > java.lang.NullPointerException
        > at org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(Unknown
        > Source)
        > at org.apache.batik.css.engine.CSSEngine.getComputedStyle(Unknown
        > Source)
        > at org.apache.batik.bridge.CSSUtilities.getComputedStyle(Unknown
        > Source)
        > at org.apache.batik.bridge.CSSUtilities.convertDisplay(Unknown Source)
        > at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source)
        > at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source)
        > at org.apache.batik.bridge.GVTBuilder.build(Unknown Source)
        > at
        > org.apache.fop.render.pdf.PDFSVGHandler.renderSVGDocument(PDFSVGHandler.java:188)
        >
        > ---------------------------------------
        >
        > see https://issues.apache.org/bugzilla/show_bug.cgi?id=46418
        >
        > I guess, there are more threading issues with Batik SVG...
        >

        Show
        Jeremias Maerki added a comment - A similar bug has been fixed in FOP Trunk as is noted in this bug. Does this error occur with the current FOP Trunk? (In reply to comment #3) > I got a NullPointerException during FOP processing while do transformations > were processing concurrently. Both include (the same) SVG image files. > > ----------------- > The attribute "style" represents an invalid CSS declaration ("fill:#ef7b00; > fill-rule:nonzero; stroke:none; stroke-width:1; stroke-linecap:butt; > stroke-linejoin:miter; stroke-dasharray:none;"). > Original message: > java.lang.NullPointerException > org.w3c.dom.DOMException: file:/C:/Programme/ddf/xml/images/V10271.svg: > The attribute "style" represents an invalid CSS declaration ("fill:#ef7b00; > fill-rule:nonzero; stroke:none; stroke-width:1; stroke-linecap:butt; > stroke-linejoin:miter; stroke-dasharray:none;"). > Original message: > java.lang.NullPointerException > at org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap(Unknown > Source) > at org.apache.batik.css.engine.CSSEngine.getComputedStyle(Unknown > Source) > at org.apache.batik.bridge.CSSUtilities.getComputedStyle(Unknown > Source) > at org.apache.batik.bridge.CSSUtilities.convertDisplay(Unknown Source) > at org.apache.batik.bridge.GVTBuilder.buildGraphicsNode(Unknown Source) > at org.apache.batik.bridge.GVTBuilder.buildComposite(Unknown Source) > at org.apache.batik.bridge.GVTBuilder.build(Unknown Source) > at > org.apache.fop.render.pdf.PDFSVGHandler.renderSVGDocument(PDFSVGHandler.java:188) > > --------------------------------------- > > see https://issues.apache.org/bugzilla/show_bug.cgi?id=46418 > > I guess, there are more threading issues with Batik SVG... >
        Hide
        M.H. added a comment -

        As this is a multi-threading issue, it's hard to reproduce. I throw lots of jobsat the application but wasn't able to reproduce it for now (with FOP 0.95).

        Show
        M.H. added a comment - As this is a multi-threading issue, it's hard to reproduce. I throw lots of jobsat the application but wasn't able to reproduce it for now (with FOP 0.95).
        Hide
        Alexios Giotis added a comment -

        I can confirm that this issue is valid for FOP 1.0. A workaround is to use a different instance of FopFactory per thread.

        Show
        Alexios Giotis added a comment - I can confirm that this issue is valid for FOP 1.0. A workaround is to use a different instance of FopFactory per thread.
        Hide
        Alexios Giotis added a comment -

        The patch is attached after a short discussion in the fop-dev mailing list. Shortly, in PDFImageHandlerSVG.handleImage() the SVG document is not cloned but in other places it is. Examples of cloning are in ImageConverterSVG2G2D, AbstractGenericSVGHandler, AFPImageHandlerSVG, AFPSVGHandler, Java2DSVGHandler, PSSVGHandler.

        Before the patch, in a multi-threaded environment parsing of the SVG documents was corrupted with a probability close to 80%. After this, the errors can not be reproduced. This patch contains the smallest change I could do, is for a single file and should be safe to apply.

        On a side note, normally I would first try to gather the building of the GraphicsNode in a single place and then avoid the document cloning by serializing only the parsing of the SVG. But that would affect more files / projects and would make the processing of the patch more difficult.

        Show
        Alexios Giotis added a comment - The patch is attached after a short discussion in the fop-dev mailing list. Shortly, in PDFImageHandlerSVG.handleImage() the SVG document is not cloned but in other places it is. Examples of cloning are in ImageConverterSVG2G2D, AbstractGenericSVGHandler, AFPImageHandlerSVG, AFPSVGHandler, Java2DSVGHandler, PSSVGHandler. Before the patch, in a multi-threaded environment parsing of the SVG documents was corrupted with a probability close to 80%. After this, the errors can not be reproduced. This patch contains the smallest change I could do, is for a single file and should be safe to apply. On a side note, normally I would first try to gather the building of the GraphicsNode in a single place and then avoid the document cloning by serializing only the parsing of the SVG. But that would affect more files / projects and would make the processing of the patch more difficult.
        Hide
        Alexios Giotis added a comment -

        Attachment bugzilla46360.patch.txt has been added with description: Patch to clone the SVG document inside PDFImageHandlerSVG

        Show
        Alexios Giotis added a comment - Attachment bugzilla46360.patch.txt has been added with description: Patch to clone the SVG document inside PDFImageHandlerSVG
        Hide
        Jeremias Maerki added a comment -

        Patch applied: http://svn.apache.org/viewvc?rev=997599&view=rev
        Thanks, Alexis.

        One more fix here:
        http://svn.apache.org/viewvc?rev=997602&view=rev

        That should now be all.

        Show
        Jeremias Maerki added a comment - Patch applied: http://svn.apache.org/viewvc?rev=997599&view=rev Thanks, Alexis. One more fix here: http://svn.apache.org/viewvc?rev=997602&view=rev That should now be all.

          People

          • Assignee:
            fop-dev
            Reporter:
            Jeremias Maerki
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development