Bug #6265: NPE in net.sf.saxon.functions.Contains - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #6265

closed

NPE in net.sf.saxon.functions.Contains

Added by Radu Coravu 5 months ago. Updated 5 months ago.

Status:

Closed

Priority:

Low

Assignee:

Michael Kay

Category:

Internals

Sprint/Milestone:

Start date:

2023-11-29

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

12, trunk

Fix Committed on Branch:

12, trunk

Fixed in Maintenance Release:

12.4

Platforms:

.NET, Java

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

Actions

Copy link

Updated by Michael Kay 5 months ago

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.

Actions

Copy link

Updated by Michael Kay 5 months ago

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)

Actions

Copy link

Updated by Michael Kay 5 months ago

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.

Actions

Copy link

Updated by Radu Coravu 5 months ago

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.

Actions

Copy link