Bug #3070: NullPointerException at gen_CompiledFilterIterator_...matches... for selectors and abstract types - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #3070

closed

NullPointerException at gen_CompiledFilterIterator_...matches... for selectors and abstract types

Added by Petr K almost 8 years ago. Updated over 7 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

Schema-Aware processing

Sprint/Milestone:

Start date:

2016-12-13

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

9.6, 9.7, trunk

Fix Committed on Branch:

9.6, 9.7, trunk

Fixed in Maintenance Release:

9.7.0.18

Platforms:

Description

i get NullPointerException in runtime for attached test case:

Exception in thread "main" java.lang.NullPointerException

at gen_CompiledFilterIterator_9.matches(:5)

at com.saxonica.ee.bytecode.iter.CompiledFilterIterator.next(CompiledFilterIterator.java:46)

at net.sf.saxon.om.FocusTrackingIterator.next(FocusTrackingIterator.java:61)

at com.saxonica.ee.bytecode.iter.CompiledFilterIterator.next(CompiledFilterIterator.java:45)

at net.sf.saxon.om.FocusTrackingIterator.next(FocusTrackingIterator.java:61)

at net.sf.saxon.expr.ContextMappingIterator.next(ContextMappingIterator.java:59)

at gen_CompiledBlockIterator_1.next(:9)

at EE_local_test_01430290781.iterate(:9)

at com.saxonica.ee.bytecode.CompiledExpression.iterate(CompiledExpression.java:200)

at net.sf.saxon.value.Closure.iterate(Closure.java:189)

at EE_main_151403658846.iterate(:13)

at com.saxonica.ee.bytecode.CompiledExpression.iterate(CompiledExpression.java:200)

at net.sf.saxon.query.XQueryExpression.iterator(XQueryExpression.java:323)

at com.saxonica.xqj.SaxonXQPreparedExpression.executeQuery(SaxonXQPreparedExpression.java:93)

at com.saxonica.xqj.SaxonXQExpression.executeQuery(SaxonXQExpression.java:96)

at Run.main(Run.java:21)

Files

AbstractType.zip (2.49 KB) AbstractType.zip

Petr K, 2016-12-13 13:26

Related issues

Actions

Copy link

Updated by O'Neil Delpratt almost 8 years ago

Category set to Byte code generation
Status changed from New to In Progress
Assignee set to O'Neil Delpratt

Thanks for reporting the NPE you have found. I was able to reproduce the NPE with the zip file you sent. We are currently investigating this bug issue which is related to the bytecode generation feature.

As a workaround you can switch off the bytecode generation feature in your java problem as follows:

ds.setProperty(FeatureKeys.GENERATE_BYTE_CODE, "off");

From the command-line you would do the following: --generateByteCode:off

Actions

Copy link

Updated by O'Neil Delpratt almost 8 years ago

Status changed from In Progress to Resolved
% Done changed from 0 to 100
Applies to branch 9.6, 9.8 added
Fix Committed on Branch 9.6, 9.7, 9.8 added

Bug fix applied in the FilterExpressionCompiler. Incorrect conditional statement: Failing to generate the NonNumeric filter iterator.

Actions

Copy link

Updated by O'Neil Delpratt almost 8 years ago

Fixed in Maintenance Release 9.7.0.15 added

Bug fix applied to the Saxon 9.7.0.15 maintenance release. Close bug issue when patch applied to 9.6 maintenance release

Actions

Copy link

Updated by O'Neil Delpratt almost 8 years ago

Status changed from Resolved to In Progress

Reopening this bug as it has been reported in bug issue #3127 to be still present in the maintenance release 9.7.0.15.

Actions

Copy link

Updated by O'Neil Delpratt almost 8 years ago

Copied to Bug #3127: Bug #3070 is still there added

Actions

Copy link

Updated by Petr K over 7 years ago

workaround brings very critical bug https://saxonica.plan.io/issues/3152

please fix this bug ASAP

Actions

Copy link

Updated by Michael Kay over 7 years ago

Category changed from Byte code generation to Schema-Aware processing
Assignee changed from O'Neil Delpratt to Michael Kay

The static type inferencing is making an incorrect inference about the cardinality of object/@attr1, and in consequence, the bytecode generator is not generating code to take account of the fact that the attribute might be absent.

Specifically, the code in UserComplexType.getAttributeUseCardinality() searches the types derived by extension from the known (abstract) type, but if it finds one derived type on which the attribute is mandatory, it is wrongly assuming that it is mandatory on all such types.

Actions

Copy link