Fop
  1. Fop
  2. FOP-1185

Null Pointer Exception (when a table cloned due to a retrieve-marker operation)

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: 0.92
    • Fix Version/s: None
    • Component/s: renderer/pdf
    • Labels:
      None
    • Environment:
      Operating System: other
      Platform: PC
    • External issue ID:
      39560

      Description

      I got a NPE rendering PDF documents. There are no other messages! Any idea?

      Regards,

      Joachim

      6359 [WT4] WARN Converter - Converter.run: Retrying FO --> PDF in thread 4
      java.lang.NullPointerException
      at org.apache.fop.fo.flow.TableRow.addChildNode(TableRow.java:193)
      at org.apache.fop.fo.FONode.clone(FONode.java:83)
      at org.apache.fop.fo.FObj.clone(FObj.java:96)
      at org.apache.fop.fo.flow.RetrieveMarker.cloneSubtree(RetrieveMarker.java:143)
      at org.apache.fop.fo.flow.RetrieveMarker.cloneSubtree(RetrieveMarker.java:145)
      at org.apache.fop.fo.flow.RetrieveMarker.cloneSubtree(RetrieveMarker.java:145)
      at org.apache.fop.fo.flow.RetrieveMarker.cloneSubtree(RetrieveMarker.java:145)
      at org.apache.fop.fo.flow.RetrieveMarker.cloneFromMarker(RetrieveMarker.java:163)
      at org.apache.fop.fo.flow.RetrieveMarker.bindMarker(RetrieveMarker.java:214)
      at
      org.apache.fop.layoutmgr.PageSequenceLayoutManager.resolveRetrieveMarker(PageSequenceLayoutManager.java:653)
      at
      org.apache.fop.layoutmgr.AbstractLayoutManager.createChildLMs(AbstractLayoutManager.java:247)
      at
      org.apache.fop.layoutmgr.BlockLayoutManager$ProxyLMiter.createNextChildLMs(BlockLayoutManager.java:146)
      at
      org.apache.fop.layoutmgr.BlockLayoutManager$ProxyLMiter.hasNext(BlockLayoutManager.java:139)
      at
      org.apache.fop.layoutmgr.BlockLayoutManager.createNextChildLMs(BlockLayoutManager.java:159)
      at org.apache.fop.layoutmgr.LMiter.hasNext(LMiter.java:39)
      at
      org.apache.fop.layoutmgr.AbstractLayoutManager.getChildLM(AbstractLayoutManager.java:107)
      at
      org.apache.fop.layoutmgr.BlockStackingLayoutManager.getNextKnuthElements(BlockStackingLayoutManager.java:258)
      at
      org.apache.fop.layoutmgr.BlockLayoutManager.getNextKnuthElements(BlockLayoutManager.java:105)
      at
      org.apache.fop.layoutmgr.table.TableCellLayoutManager.getNextKnuthElements(TableCellLayoutManager.java:160)
      at
      org.apache.fop.layoutmgr.table.TableContentLayoutManager.createElementsForRowGroup(TableContentLayoutManager.java:467)
      at
      org.apache.fop.layoutmgr.table.TableContentLayoutManager.getKnuthElementsForRowIterator(TableContentLayoutManager.java:237)
      at
      org.apache.fop.layoutmgr.table.TableContentLayoutManager.getNextKnuthElements(TableContentLayoutManager.java:176)
      at
      org.apache.fop.layoutmgr.table.TableLayoutManager.getNextKnuthElements(TableLayoutManager.java:233)
      at
      org.apache.fop.layoutmgr.StaticContentLayoutManager$StaticContentBreaker.getNextKnuthElements(StaticContentLayoutManager.java:306)
      at
      org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockList(AbstractBreaker.java:502)
      at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:252)
      at
      org.apache.fop.layoutmgr.StaticContentLayoutManager.doLayout(StaticContentLayoutManager.java:230)
      at
      org.apache.fop.layoutmgr.PageSequenceLayoutManager.layoutSideRegion(PageSequenceLayoutManager.java:688)
      at
      org.apache.fop.layoutmgr.PageSequenceLayoutManager.finishPage(PageSequenceLayoutManager.java:695)
      at
      org.apache.fop.layoutmgr.PageSequenceLayoutManager.makeNewPage(PageSequenceLayoutManager.java:660)
      at
      org.apache.fop.layoutmgr.PageSequenceLayoutManager.handleBreakTrait(PageSequenceLayoutManager.java:729)
      at
      org.apache.fop.layoutmgr.PageSequenceLayoutManager.access$100(PageSequenceLayoutManager.java:57)
      at
      org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.startPart(PageSequenceLayoutManager.java:467)
      at org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.java:370)
      at org.apache.fop.layoutmgr.AbstractBreaker.addAreas(AbstractBreaker.java:321)
      at
      org.apache.fop.layoutmgr.PageSequenceLayoutManager$PageBreaker.doPhase3(PageSequenceLayoutManager.java:331)
      at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:296)
      at org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:220)
      at
      org.apache.fop.layoutmgr.PageSequenceLayoutManager.activateLayout(PageSequenceLayoutManager.java:152)
      at org.apache.fop.area.AreaTreeHandler.endPageSequence(AreaTreeHandler.java:320)
      at org.apache.fop.fo.pagination.PageSequence.endOfNode(PageSequence.java:147)
      at org.apache.fop.fo.FOTreeBuilder$MainFOHandler.endElement(FOTreeBuilder.java:357)
      at org.apache.fop.fo.FOTreeBuilder.endElement(FOTreeBuilder.java:193)
      at
      org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1050)
      at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
      at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
      at
      org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
      Source)
      at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
      Source)
      at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
      at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
      at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
      at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
      at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
      at
      org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:452)
      at Converter.run(Converter.java:284)

      1. output.fo
        67 kB
        Joachim Unger

        Activity

        Hide
        Chris Bowditch added a comment -

        Please attached a small FO file that demonstrates the problem

        Show
        Chris Bowditch added a comment - Please attached a small FO file that demonstrates the problem
        Hide
        Joachim Unger added a comment -

        I tried to reduce some information in the fo-file because the data is
        confidential. But then the error disappears. Sorry. I will need some time to
        find an example.

        Might it be a memory problem or a problem with tables (many rows, marker in
        every tow) over more than one page?

        All my other documents were rendered perfectly.

        Regards,

        Joachim

        Show
        Joachim Unger added a comment - I tried to reduce some information in the fo-file because the data is confidential. But then the error disappears. Sorry. I will need some time to find an example. Might it be a memory problem or a problem with tables (many rows, marker in every tow) over more than one page? All my other documents were rendered perfectly. Regards, Joachim
        Hide
        Jeremias Maerki added a comment -

        Looking at the stack trace it must be something with the combination of
        retrieve-marker and tables. The exception handles because usedColumnIndices is
        null. usedColumnIndices is instantiated a few lines above but only if certain
        conditions are met. There's also another line in TableRow.startOfNode() which
        gets the usedColumnIndices from the parent table-body. Try debugging in that area.

        Show
        Jeremias Maerki added a comment - Looking at the stack trace it must be something with the combination of retrieve-marker and tables. The exception handles because usedColumnIndices is null. usedColumnIndices is instantiated a few lines above but only if certain conditions are met. There's also another line in TableRow.startOfNode() which gets the usedColumnIndices from the parent table-body. Try debugging in that area.
        Hide
        Joachim Unger added a comment -

        Attachment output.fo has been added with description: FO-Input not converted by FOP 0.92

        Show
        Joachim Unger added a comment - Attachment output.fo has been added with description: FO-Input not converted by FOP 0.92
        Hide
        Jeremias Maerki added a comment -

        Ok, it looks like it's really the column handling code in TableRow that's
        falling appart as soon as a table is cloned due to a retrieve-marker operation
        from a marker which contains a table. I don't see a solution, yet. I'll build a
        small test case we can put in the test suite. If anyone has ideas how to fix
        this....

        Show
        Jeremias Maerki added a comment - Ok, it looks like it's really the column handling code in TableRow that's falling appart as soon as a table is cloned due to a retrieve-marker operation from a marker which contains a table. I don't see a solution, yet. I'll build a small test case we can put in the test suite. If anyone has ideas how to fix this....
        Hide
        Jeremias Maerki added a comment -

        Test case added: http://svn.apache.org/viewvc?rev=407588&view=rev
        Any table put in a marker fails when it's referenced through a retrieve-marker.

        Show
        Jeremias Maerki added a comment - Test case added: http://svn.apache.org/viewvc?rev=407588&view=rev Any table put in a marker fails when it's referenced through a retrieve-marker.
        Hide
        Andreas L. Delmelle added a comment -

        I think I see what the problem is here... expect a fix soon.

        See TableBody.endOfNode(). usedColumnIndices is set to null, as I mistakenly supposed this wouldn't be
        used again... Overlooked the case of the table being cloned due to marker-retrieval

        Show
        Andreas L. Delmelle added a comment - I think I see what the problem is here... expect a fix soon. See TableBody.endOfNode(). usedColumnIndices is set to null, as I mistakenly supposed this wouldn't be used again... Overlooked the case of the table being cloned due to marker-retrieval
        Hide
        Andreas L. Delmelle added a comment -

        Looking at what happens a bit more closely: I was on the right track --in thinking that it was unnecessary
        to keep the BitSet alive after the TableBody/TableRow node ended.

        The whole column-numbering process should not be repeated at any rate, since it was already completed
        when that fragment was parsed, so the TableColumn/TableCell instances will, at that point already contain
        the correct initial values.

        Back to the investigation

        Show
        Andreas L. Delmelle added a comment - Looking at what happens a bit more closely: I was on the right track --in thinking that it was unnecessary to keep the BitSet alive after the TableBody/TableRow node ended. The whole column-numbering process should not be repeated at any rate, since it was already completed when that fragment was parsed, so the TableColumn/TableCell instances will, at that point already contain the correct initial values. Back to the investigation
        Hide
        Andreas L. Delmelle added a comment -

        OK, yet another one of my gut feelings at the time has hereby been proven correct: putting that stuff in
        addChildNode() wasn't such a good idea... Sorry :/

        Now as for the solution: I'm thinking along the lines of moving the related code from i.e.
        TableRow.addChildNode() to TableCell.endOfNode(), since the latter is guaranteed to occur only once per
        actual table-cell --regardless of whether it gets cloned afterwards due to marker-retrieval. The same info
        will be available, only through the parent instead of directly.

        Shouldn't prove to be too difficult, but before I begin:
        Does anyone disagree with the change described above?

        Show
        Andreas L. Delmelle added a comment - OK, yet another one of my gut feelings at the time has hereby been proven correct: putting that stuff in addChildNode() wasn't such a good idea... Sorry :/ Now as for the solution: I'm thinking along the lines of moving the related code from i.e. TableRow.addChildNode() to TableCell.endOfNode(), since the latter is guaranteed to occur only once per actual table-cell --regardless of whether it gets cloned afterwards due to marker-retrieval. The same info will be available, only through the parent instead of directly. Shouldn't prove to be too difficult, but before I begin: Does anyone disagree with the change described above?
        Hide
        Andreas L. Delmelle added a comment -

        OK. Good news first: I managed to fix the NPE as described, by moving the code related to updating the
        table FOs column indices to TableCell.startOfNode() / TableCell.endOfNode(). Still have to do the same for
        the columns...

        Bad news: still have to investigate why our testcase now ends up being... completely empty ?

        Nothing but <areaTree />...

        Show
        Andreas L. Delmelle added a comment - OK. Good news first: I managed to fix the NPE as described, by moving the code related to updating the table FOs column indices to TableCell.startOfNode() / TableCell.endOfNode(). Still have to do the same for the columns... Bad news: still have to investigate why our testcase now ends up being... completely empty ? Nothing but <areaTree />...
        Hide
        Andreas L. Delmelle added a comment -

        NPE is fixed, but I wouldn't use tables in markers just yet... there are still remaining problems.

        Show
        Andreas L. Delmelle added a comment - NPE is fixed, but I wouldn't use tables in markers just yet... there are still remaining problems.
        Hide
        Andreas L. Delmelle added a comment -

        OK, fixed in FOP Trunk.

        More info on the remaining problem:

        It seems like the layoutengine currently tries to calculate widths for the descendants of the markers
        contained within it, which seems to lead to errors in AbstractBaseLM.getBaseLength()... ? Still have to
        investigate a bit further. If anyone else feels like looking at this, be my guest

        If you use absolute widths on the tables instead of a percentage, everything works and displays nicely.

        Show
        Andreas L. Delmelle added a comment - OK, fixed in FOP Trunk. More info on the remaining problem: It seems like the layoutengine currently tries to calculate widths for the descendants of the markers contained within it, which seems to lead to errors in AbstractBaseLM.getBaseLength()... ? Still have to investigate a bit further. If anyone else feels like looking at this, be my guest If you use absolute widths on the tables instead of a percentage, everything works and displays nicely.
        Hide
        Glenn Adams added a comment -

        batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed

        Show
        Glenn Adams added a comment - batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development