Bug #5890
closed
Saxon 12 NPE
0%
Description
It has taken me a long time to isolate a test case for this bug.
It originally presented as a random failure. With Saxon 11.5 (run-115.sh), running the XSpec test causes a random failure in the 693rd test. Every attempt to reduce or simplify the test that I've tried so far has caused the test to succeed.
On a whim, I tried it with Saxon 12 (run-12.sh) fully expecting it to succeed. Instead it fails quickly with a NPE:
java.lang.NullPointerException
at net.sf.saxon.expr.parser.LoopLifter.markDependencies(LoopLifter.java:221)
at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:171)
at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:174)
at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:174)
at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:174)
at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:174)
at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:174)
at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:174)
at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:174)
at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:153)
at net.sf.saxon.expr.parser.LoopLifter.process(LoopLifter.java:53)
at net.sf.saxon.expr.parser.ExpressionTool.optimizeComponentBody(ExpressionTool.java:978)
at net.sf.saxon.style.XSLTemplate.optimize(XSLTemplate.java:1014)
at net.sf.saxon.style.PrincipalStylesheetModule.optimizeTopLevel(PrincipalStylesheetModule.java:1496)
at net.sf.saxon.style.PrincipalStylesheetModule.compile(PrincipalStylesheetModule.java:1315)
at net.sf.saxon.style.Compilation.compilePackage(Compilation.java:324)
at net.sf.saxon.style.StylesheetModule.loadStylesheet(StylesheetModule.java:246)
at net.sf.saxon.style.Compilation.compileSingletonPackage(Compilation.java:113)
at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:969)
at net.sf.saxon.Transform.doTransform(Transform.java:777)
at net.sf.saxon.Transform.main(Transform.java:83)
Is this related to the failure in Saxon 11.5? I've no idea.
Files
Updated by Michael Kay about 1 year ago
An NPE at this point typically indicates that the expression tree contains a pair of expression nodes (P, C) such that C is the child of P, but P is not the parent of C. This inconsistency is discovered during loop-lifting, but it is generally the consequence of an earlier problem, and that problem is usually that a child expression has been attached to the tree without first copying it, leading it to point to its new parent, while still being referenced from its old parent. The corruption can usually be confirmed by uncommenting the call on exp.verifyParentPointers() at line 47 of LoopLifter.
Check that you are not hitting bug #5888 (which is new in 12.x)
Updated by Norm Tovey-Walsh about 1 year ago
Yes, running with the current main branch demonstrates that #5888 is probably the cause of the NPE I saw with 12.0. Now trying to see if I can reproduce the failure on the 693rd test with main.
Updated by Norm Tovey-Walsh about 1 year ago
Indeed, main succeeds and cannot be persuaded to fail. 11.5 still fails after 693 tests. :-(
Updated by Norm Tovey-Walsh about 1 year ago
I'm giving up on this one. The slightest change, even attempting to xsl:message the expected result (which is what appears to be wrong, even though it's just loaded from a file) causes the test to pass. It doesn't fail when run under the debugger either. There's something going on, but I've run out of ideas about how to expose it.
Updated by Norm Tovey-Walsh about 1 year ago
I have a new hypothesis. The problem occurs in the stylesheet that's formatting the XSpec test results. It appears to happen when there are a large number of failures. In the case of failures, the stylesheet attempts to compare the expected result and the actual result to produce an easy to read summary of the differences. I think it's possible that the algorithm that does that is exponential and just takes a long time if there are a lot of differences. (Or perhaps if the files to be compared are quite large?)
That doesn't explain the xsl:message behavior, of course, so I could be wrong. Or maybe there are a few different issues here.
Updated by Norm Tovey-Walsh 10 months ago
- Status changed from AwaitingInfo to Rejected
I've mostly satisfied myself that the performance problem is a consequence of the comparison algorithm, nothing to do with the processor. I'm going to close this. If it recurs in some more accessible context, I'll dig in again.
Please register to edit this issue
.