Bug #5699: Bug in saxon XQuery Parser: throws nullpointer in "satisfies"-clause - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #5699

closed

Bug in saxon XQuery Parser: throws nullpointer in "satisfies"-clause

Added by Wolfgang May about 2 years ago. Updated almost 2 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

Internals

Sprint/Milestone:

Start date:

2022-09-29

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

11, trunk

Fix Committed on Branch:

11, trunk

Fixed in Maintenance Release:

12.0, 11.5

Platforms:

.NET, Java

Description

SaxonJ-HE 11.4 throws a nullpointer error when parsing the following (as far as I can see syntactically correct) query (also attached as file):

or $organization in doc("http://www.dbis.informatik.uni-goettingen.de/Mondial/mondial-europe.xml")//organization where every $country in //country[population > 10000000] satisfies $country = id($organization/members/@country) (: the above syntax should be allowed but throws the error message shown below. With this -equivalent- syntax, the query is parsed and evaluated correctly: satisfies $country = $organization/members/id(@country) :) return $organization/name[1]

java.lang.NullPointerException at net.sf.saxon.expr.parser.LoopLifter.markDependencies(LoopLifter.java:172) at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:116) at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:126) at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:126) at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:126) at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:126) at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:105) at net.sf.saxon.expr.parser.LoopLifter.process(LoopLifter.java:54) at net.sf.saxon.query.XQueryExpression.(XQueryExpression.java:108) at net.sf.saxon.Configuration.makeXQueryExpression(Configuration.java:3576) at net.sf.saxon.query.XQueryParser.makeXQueryExpression(XQueryParser.java:187) at net.sf.saxon.query.StaticQueryContext.compileQuery(StaticQueryContext.java:562) at net.sf.saxon.query.StaticQueryContext.compileQuery(StaticQueryContext.java:624) at net.sf.saxon.s9api.XQueryCompiler.compile(XQueryCompiler.java:650) at net.sf.saxon.Query.compileQuery(Query.java:864) at net.sf.saxon.Query.doQuery(Query.java:327) at net.sf.saxon.Query.main(Query.java:103) java.lang.NullPointerException at net.sf.saxon.expr.parser.LoopLifter.markDependencies(LoopLifter.java:172) at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:116) at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:126) at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:126) at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:126) at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:126) at net.sf.saxon.expr.parser.LoopLifter.gatherInfo(LoopLifter.java:105) at net.sf.saxon.expr.parser.LoopLifter.process(LoopLifter.java:54) at net.sf.saxon.query.XQueryExpression.(XQueryExpression.java:108) at net.sf.saxon.Configuration.makeXQueryExpression(Configuration.java:3576) at net.sf.saxon.query.XQueryParser.makeXQueryExpression(XQueryParser.java:187) at net.sf.saxon.query.StaticQueryContext.compileQuery(StaticQueryContext.java:562) at net.sf.saxon.query.StaticQueryContext.compileQuery(StaticQueryContext.java:624) at net.sf.saxon.s9api.XQueryCompiler.compile(XQueryCompiler.java:650) at net.sf.saxon.Query.compileQuery(Query.java:864) at net.sf.saxon.Query.doQuery(Query.java:327) at net.sf.saxon.Query.main(Query.java:103) Fatal error during query: java.lang.NullPointerException: (no message)

Files

xqbug.xq (3.2 KB) xqbug.xq

Wolfgang May, 2022-09-29 20:57

Actions

Copy link

Updated by Michael Kay about 2 years ago

Category set to Internals
Assignee set to Michael Kay
Priority changed from Low to Normal

Thanks for reporting it: problem reproduced.

It is of course a bug in the optimiser, not in the parser. If you need a workaround, you can suppress the loop-lifting optimization with the flag -opt:-l (or an equivalent configuration setting in the s9api API). That's ('minus', 'letter ell').

Actions

Copy link

Updated by Michael Kay about 2 years ago

We're wrapping the entire query in a LetExpression that does

let $vv:var := . return EXPR

and within EXPR, references to "." are replaced by $vv:var - in particular //country becomes $vv:var/descendant::country.

The LoopLifter works its way down the tree from this LetExpression, and then works its way back up again, and for some reason, the parent pointer in EXPR points to a different object instance from the one we started at.

The LetExpression is created by FLWORExpression..optimize() calling tryToFactorOutDot(). The thinking here is that if any dependencies on . are removed from where clauses, the where clauses can often be rewritten as predicates on the selection in a for clause.

Turns out we are making EXPR be a child of the new LetExpression without making the LetExpression become the parent of EXPR. The only safe way to do such tree manipulations is to make a copy of the child expression, and we're failing to do that on this path.

Actions

Copy link

Updated by Michael Kay about 2 years ago

As a matter of interest, I wonder if the author of the query intended //country to search within the document at "http://www.dbis.informatik.uni-goettingen.de/Mondial/mondial-europe.xml", rather than within the document supplied as the context item to the query?

Actions

Copy link

Updated by Wolfgang May about 2 years ago

Ups, sorry. I added the explicit outer "doc("...")" only later for the bug report to make the query self-contained. Originally, it is the context document.

Actions

Copy link