Saxon

Thanks for reporting it. Multi-threading errors (indeed, many errors) are difficult to track down unless we can reproduce them. If you can send the stylesheet that causes this, we'll be happy to take a look at it.

In the absence of that, I think I can make a guess. When calling a user-defined function, there are a number of different strategies (varieties of eager and lazy evaluation) that we use for evaluating the arguments. Normally the strategy for each argument is decided statically (at compile time). However, if we find at run-time that for some reason the strategy hasn't yet been computed, then we compute it on first evaluation. Because this updates the expression tree, it should be synchronized, but it isn't. We can certainly add synchronization to this method, but I would like to reproduce the error first so that I have confidence in the fix; and since we're already on a recovery path here, I would like to see why it is that the work wasn't done at compile time.

Hi Mr. Michael,

I sent you an email and i hope that the provided content would help you to identify the issue root cause.

Regards,

Oussama

Hello Mr. Michael,

Could you please provide us the Saxonica package containing the fix and we will test it in our environment.

The problem is recurrent in the production environment and we hope to fix it as soon as possible.

Kind regards,

There are two problems here.

The first is that the argument evaluation modes for a stylesheet function call are not being computed at compile time as they should be. Or rather, they are being computed, but they are then being reset. After a tree rewrite, resetLocalProperties() is called to unset cached expression properties, in case the rewrite has invalidated the properties. In this example the final phase of optimization is to extract global variables, and this triggers a call on resetLocalProperties, which are therefore unset when execution commences.

The second problem is that the recovery action, which computes argument evaluation modes at run-time if they are not available in the expression tree, is not thread safe. The code does "if (evaluationModes == null) computeEvaluationModes()", where the computeEvaluationModes() method is synchronised; but if thread A is computing the evaluation modes, thread B will see a non-null value for evaluationModes, and use the data even though it has not been fully computed.

Let's address the compile-time story first.

The argument evaluation modes are needed only at run-time, unlike most of the properties we store on the expression tree which are used primarily at compile time. So it makes sense to compute them only at the end of optimization. Fortunately we have a mechanism for doing this in ExpressionTool.optimizeComponentBody().

I have implemented this change and it appears to be OK (I've got a number of test failures that need to be investigated but they seem unrelated.)

Further testing revealed that the fix is incorrect for XQuery - committing further changes for that case.