Bug #3478
closed
Stackoveflow in UserComplexType.getDescendantElementCardinality
Category:
Schema-Aware processing
Applies to branch:
9.7, 9.8
Fix Committed on Branch:
9.7, 9.8, trunk
Fixed in Maintenance Release:
Description
Using Saxon EE to transform an XML using an XSLT which has an xs:import-schema yelds a StackOverflow:
java.lang.StackOverflowError
at com.saxonica.ee.schema.ElementParticle.gatherAllPermittedElements(ElementParticle.java:316)
at com.saxonica.ee.schema.ModelGroup.gatherAllPermittedElements(ModelGroup.java:524)
at com.saxonica.ee.schema.ModelGroupParticle.gatherAllPermittedElements(ModelGroupParticle.java:211)
at com.saxonica.ee.schema.UserComplexType.gatherAllPermittedChildren(UserComplexType.java:2311)
at com.saxonica.ee.schema.UserComplexType.gatherAllPermittedDescendants(UserComplexType.java:2337)
at com.saxonica.ee.schema.UserComplexType.gatherAllPermittedDescendants(UserComplexType.java:2351)
at com.saxonica.ee.schema.UserComplexType.gatherAllPermittedDescendants(UserComplexType.java:2351)
at com.saxonica.ee.schema.UserComplexType.getDescendantElementCardinality(UserComplexType.java:2456)
at com.saxonica.ee.schema.UserComplexType.getDescendantElementCardinality(UserComplexType.java:2459)
at com.saxonica.ee.schema.UserComplexType.getDescendantElementCardinality(UserComplexType.java:2459)
at com.saxonica.ee.schema.UserComplexType.getDescendantElementCardinality(UserComplexType.java:2459)
Files
Our end user provided us with samples, I need to check with them to see if it's OK to share them directly here or if I can email them directly to Michael K.
End user gave his blessings and I'm attaching the samples to reproduce the problem.
- Category set to Schema-Aware processing
- Assignee set to Michael Kay
Reproduced on 9.7 and 9.8. (On 9.8 it is masked by bug #3781).
As far as I can see this is a bug that has been in the code "for ever". This particular path, which attempts to determine the cardinality of an expression such as descendant::x by use of schema information, makes no serious attempt to deal with types that have a recursive definition.
Note that this does not affect schema validation, only schema-aware static analysis of XSLT and XQuery code (which has probably been exposed to a rather smaller set of schemas...)
- Status changed from New to Resolved
- Priority changed from High to Normal
- Applies to branch 9.7, 9.8 added
- Fix Committed on Branch 9.7, 9.8, trunk added
Actually, there's a code line UserComplexType#2448 which tests
if (child == elementName)
At one time this was testing integer fingerprints, but the code was rewritten to use StructuredQName objects, which means the "==" should have been changed to a call on equals(). Although it's not absolutely self-evident, I've persuaded myself (and done a bit of testing) that this change will always cause the recursion to terminate.
There's a pathological case where a child element requires exactly one occurrence of itself as a child: such a type has no valid (finite) instances, but we still don't want stylesheet analysis to fail. Although I haven't managed to create such a test case I think it's safer to terminate the recursion when the computed cardinality is 1-or-more as well as when it is 0-or-more as currently.
Thanks for the fix, I tested it on the 9.7 branch and it seems to work. End user says this situation did not happen with Saxon 9.6 and indeed from what I tested 9.6 did not seem to have this problem...
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.8.0.6 added
Bug fix applied in the Saxon 9.8.0.6 maintenance release. Leave open until bug fix applied in the 9.7 maintenance release
- Status changed from Resolved to Closed
- Fixed in Maintenance Release 9.7.0.21 added
Bug fix applied in the Saxon 9.7.0.21 maintenance release.
Please register to edit this issue
Also available in: Atom
PDF
.