Bug #3534: Simple map operator, fn:min - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #3534

closed

Simple map operator, fn:min

Added by Christian Grün over 6 years ago. Updated over 6 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Category:

Byte code generation

Sprint/Milestone:

Start date:

2017-11-16

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

9.7, 9.8, trunk

Fix Committed on Branch:

9.7, 9.8, trunk

Fixed in Maintenance Release:

9.7.0.21, 9.8.0.7

Platforms:

Description

And yet another one (that may already have been fixed?): The query (1e0, 1) ! min(.) yields this:

java.lang.NullPointerException
        at net.sf.saxon.expr.AtomicSequenceConverter$AtomicSequenceMappingFunction.mapItem(AtomicSequenceConverter.java:289)
        at net.sf.saxon.expr.AtomicSequenceConverter$AtomicSequenceMappingFunction.mapItem(AtomicSequenceConverter.java:280)
        at net.sf.saxon.expr.ItemMappingIterator.next(ItemMappingIterator.java:113)
        at EE_main_01422222071.process(file:/c:/Users/user/Desktop/query.xq:1)
        at com.saxonica.ee.bytecode.CompiledExpression.process(CompiledExpression.java:70)
        at net.sf.saxon.query.XQueryExpression.run(XQueryExpression.java:408)
        at net.sf.saxon.s9api.XQueryEvaluator.run(XQueryEvaluator.java:370)
        at net.sf.saxon.Query.runQuery(Query.java:900)
        at net.sf.saxon.Query.doQuery(Query.java:442)
        at net.sf.saxon.Query.main(Query.java:111)

Actions

Copy link

Updated by Michael Kay over 6 years ago

Category set to Byte code generation
Applies to branch 9.7 added

I can confirm that this is crashing in 9.7 but runs OK in 9.8.

Actions

Copy link

Updated by Michael Kay over 6 years ago

Status changed from New to In Progress
Priority changed from Low to Normal

Turns out it isn't really fixed in 9.8 at all; it just requires a more subtle test because by default it's masked by hotspot bytecode generation.

Actions

Copy link

Updated by Michael Kay over 6 years ago

The crash is because the static type of the first argument to min() is heterogeneous, and in consequence no converter has been allocated to handle run-time type conversion at the time bytecode is generated.

Running the interpreter under the debugger shows that it's behaving badly in that case too: the converter is allocated at run-time, but is written to the relevant node in the expression tree, causing potential multi-threading problems.

So the first part of the fix is to ensure that when a converter is allocated dynamically, the expression tree is not modified.

The second part (which fixes the bug observed here) is to force allocation of a converter before generating bytecode.

The final part is more specific to the min() function. The min() and max() functions convert untyped atomic values to xs:double regardless of the type of the other items in the sequence. So there's no good reason to delay allocating a converter until the static type of the sequence is more precisely known: it won't make any difference. This can be achieved by changing Minimax.optimizeFunctionCall() to call the factory method UntypedSequenceConverter.makeUntypedSequenceConverter() in place of the simple constructor.

Actions

Copy link