Bug #6435
closed
net.sf.saxon.trans.XPathException: Accumulator Q{http://ns.saxonica.com/anonymous-type}n1899519096 has not been declared
100%
Description
When the saxon:thread attribute is set for xsl:for-each in saxon-ee-12.4 (enterprise edition)，an error occurs occasionally. The exception stack is as follows:
SystemID: file:/data01/NewPublish/commons-java.xsl; Line#: 3083; Column#: 63 net.sf.saxon.trans.XPathException: Accumulator Q{http://ns.saxonica.com/anonymous-type}n1899519096 has not been declared at net.sf.saxon.functions.AccumulatorFn.getAccumulator(AccumulatorFn.java:83) at net.sf.saxon.functions.AccumulatorFn.getAccumulatorValue(AccumulatorFn.java:37) at net.sf.saxon.functions.AccumulatorFn.call(AccumulatorFn.java:154) at net.sf.saxon.expr.SystemFunctionCall$SystemFunctionCallElaborator.lambda$elaborateForPull$1(SystemFunctionCall.java:605) at net.sf.saxon.expr.FilterExpression$FilterExprElaborator.lambda$elaborateForPull$1(FilterExpression.java:1285) at net.sf.saxon.expr.NumberSequenceFormatter$NumberSequenceFormatterElaborator.lambda$elaborateForUnicodeString$0(NumberSequenceFormatter.java:342) at net.sf.saxon.expr.elab.StringElaborator.lambda$elaborateForItem$2(StringElaborator.java:57) at net.sf.saxon.expr.CastExpression$CastExprElaborator.lambda$elaborateForItem$0(CastExpression.java:488) at net.sf.saxon.expr.elab.ItemElaborator.lambda$elaborateForPull$0(ItemElaborator.java:36) at net.sf.saxon.expr.elab.SharedAppendEvaluator.lambda$new$1(SharedAppendEvaluator.java:42) at net.sf.saxon.expr.elab.SharedAppendEvaluator.evaluate(SharedAppendEvaluator.java:63) at net.sf.saxon.expr.SystemFunctionCall$SystemFunctionCallElaborator.lambda$elaborateForItem$6(SystemFunctionCall.java:663) at net.sf.saxon.expr.CastExpression$CastExprElaborator.lambda$elaborateForItem$0(CastExpression.java:488) at net.sf.saxon.expr.elab.ItemElaborator.lambda$elaborateForPull$0(ItemElaborator.java:36) at net.sf.saxon.expr.elab.LazyPullEvaluator.evaluate(LazyPullEvaluator.java:39) at net.sf.saxon.expr.elab.LearningEvaluator.evaluate(LearningEvaluator.java:61) at net.sf.saxon.expr.LetExpression$LetExprElaborator.lambda$setAllVariables$4(LetExpression.java:894) at net.sf.saxon.expr.LetExpression$LetExprElaborator.lambda$elaborateForPush$6(LetExpression.java:940) at net.sf.saxon.expr.instruct.Block$BlockElaborator.lambda$elaborateForPush$1(Block.java:853) at net.sf.saxon.expr.instruct.TemplateRule.applyLeavingTail(TemplateRule.java:376) at net.sf.saxon.trans.Mode.handleRuleNotNull(Mode.java:587) at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:521) at net.sf.saxon.expr.instruct.ApplyTemplates$ApplyTemplatesElaborator.lambda$elaborateForPush$1(ApplyTemplates.java:650) at net.sf.saxon.expr.instruct.Block$BlockElaborator.lambda$elaborateForPush$4(Block.java:895) at net.sf.saxon.expr.instruct.TemplateRule.applyLeavingTail(TemplateRule.java:376) at net.sf.saxon.trans.Mode.handleRuleNotNull(Mode.java:587) at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:521) at net.sf.saxon.expr.instruct.ApplyTemplates$ApplyTemplatesElaborator.lambda$elaborateForPush$1(ApplyTemplates.java:650) at net.sf.saxon.expr.instruct.Block$BlockElaborator.lambda$elaborateForPush$3(Block.java:882) at net.sf.saxon.expr.instruct.TemplateRule.applyLeavingTail(TemplateRule.java:376) at net.sf.saxon.trans.Mode.handleRuleNotNull(Mode.java:587) at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:521) at net.sf.saxon.expr.instruct.ApplyTemplates$ApplyTemplatesElaborator.lambda$elaborateForPush$1(ApplyTemplates.java:650) at net.sf.saxon.expr.elab.PushElaborator.lambda$elaborateForPull$0(PushElaborator.java:38) at net.sf.saxon.expr.instruct.Block$BlockElaborator$BlockIterator.getNthChildIterator(Block.java:832) at net.sf.saxon.expr.instruct.AbstractBlockIterator.next(AbstractBlockIterator.java:66) at net.sf.saxon.value.SequenceExtent.from(SequenceExtent.java:48) at net.sf.saxon.om.SequenceTool.toGroundedValue(SequenceTool.java:55) at com.saxonica.ee.parallel.MultithreadedContextMappingIterator.lambda$mapOneItem$0(MultithreadedContextMappingIterator.java:179) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)
Files
Updated by Michael Kay 6 months ago
Thanks for reporting it. The implementation of xsl:number uses accumulators internally for performance reasons and it looks as if there is a thread-safety issue in the way this optimization is implemented.
Updated by Michael Kay 6 months ago
I think this is probably another case where two templates are being JIT-compiled concurrently. The stack trace is very little use except that it indicates that xsl:number has allocated a synthetic accumulator name and isn't finding an accumulator with this name in the accumulator registry; this must suggest a timing glitch in OptimizerEE.optimizeNumberInstruction. I think the safest course of action is probably to replace the HashMap accumulatorsByName with a ConcurrentHashMap.
Updated by Michael Kay 6 months ago
- Category set to Multithreading
- Status changed from New to Resolved
- Assignee set to Michael Kay
- Priority changed from Low to Normal
- Applies to branch 12, trunk added
- Fix Committed on Branch 12, trunk added
- Platforms .NET, Java added
I can't be 100% sure that this will fix it, but the patch certainly improves thread safety and can't do any harm, so I'll close it as resolved on that basis.
Updated by O'Neil Delpratt 5 months ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 12.5 added
Bug fix applied in the Saxon 12.5 Maintenance release.
Please register to edit this issue
.