Bug #3478
closed
Stackoveflow in UserComplexType.getDescendantElementCardinality
100%
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
Updated by Radu Coravu about 7 years ago
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.
Updated by Radu Coravu about 7 years ago
- File stackOverflow.zip stackOverflow.zip added
End user gave his blessings and I'm attaching the samples to reproduce the problem.
Updated by Michael Kay about 7 years ago
- 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...)
Updated by Michael Kay about 7 years ago
- 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.
Updated by Radu Coravu about 7 years ago
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...
Updated by O'Neil Delpratt about 7 years ago
- % 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
Updated by O'Neil Delpratt almost 7 years ago
- 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
.