Bug #6265
closed
NPE in net.sf.saxon.functions.Contains
Applies to branch:
12, trunk
Fix Committed on Branch:
12, trunk
Fixed in Maintenance Release:
Description
The problem was initially reported here:
https://listserv.brown.edu/cgi-bin/wa?A2=ind2311&L=TEI-L&P=24616
It seems that one of our users who validates TEI XML documents using Schematron stumbled upon this NullPointerException:
java.lang.NullPointerException: Cannot invoke "String.contains(java.lang.CharSequence)" because the return value of "net.sf.saxon.expr.elab.StringEvaluator.eval(net.sf.saxon.expr.XPathContext)" is null
at net.sf.saxon.functions.Contains$ContainsFnElaborator.lambda$elaborateForBoolean$0(Contains.java:76)
at net.sf.saxon.expr.instruct.TraceExpression$TraceExpressionElaborator.lambda$elaborateForBoolean$5(TraceExpression.java:469)
at net.sf.saxon.expr.OrExpression$OrElaborator.lambda$elaborateForBoolean$0(OrExpression.java:173)
at net.sf.saxon.expr.instruct.Choose$ChooseExprElaborator.lambda$elaborateForPush$10(Choose.java:1168)
at
I'm afraid it's going to be difficult to do much with this without a repro.
There's clearly a call on fn:contains(x, y), and the code for evaluating y has returned null to represent an empty sequence when it was asked to return "" (that's elaborateForString(true)). Without knowing what kind of expression y is, we don't know where to look.
Well, there are only 12 implementations of elaborateForString() so I could start by checking them all...
One possible culprit is String_1.elaborateForString(), which evaluates the string() function.
SubstringAfter and SubstringBefore also have paths that look a bit dodgy.
TraceExpression also needs examining (possibly relevant because there is a TraceExpression on the stack)
I've eliminated string() and substring-before|after(), my suspicions now fall on TraceExpression - which will only occur if the expression is compiled with tracing enabled. I suspect Oxygen is inserting trace calls into the expression at quite a fine level of granularity, which isn't particularly easy to simulate.
I'm inclined to correct what seems to be a fairly obvious coding error in TraceExpression.evaluateForString() and ship it without a specific test case.
Thanks for the fix Michael!
I managed to compile the Schematron rules from the TEI RNG file to XSLT but just plain transforming the XML + XSLT I cannot reproduce the problem so it's probably as you said, the trace listener we add in the Schematron-based validation influences things.
- Category set to Internals
- Status changed from New to Resolved
- Assignee set to Michael Kay
- Applies to branch 12, trunk added
- Fix Committed on Branch 12, trunk added
- Platforms .NET, Java added
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 12.4 added
Bug fix applied in the Saxon 12.4 maintenance release
Please register to edit this issue
Also available in: Atom
PDF
.