This happens in the following scenario:
* single heat-engine (so no multi-engine locking paths are invoked)
* multiple stack deletes on the same stack
* when the threads are destroyed from a previous delete call so that the new delete call can acquire the lock and do the delete
I don't think this is a race as-such. The error happens when user_creds_delete is being called by the thread which is currently being killed, and the session is already in the process of being shut down.
I have a change which does a graceful stop of the threadgroup instead of a hard stop. A timeout will be added to the threadgroup waiting, to give the threads an opportunity to finish within the timeout.
This happens in the following scenario:
* single heat-engine (so no multi-engine locking paths are invoked)
* multiple stack deletes on the same stack
* when the threads are destroyed from a previous delete call so that the new delete call can acquire the lock and do the delete
I don't think this is a race as-such. The error happens when user_creds_delete is being called by the thread which is currently being killed, and the session is already in the process of being shut down.
I have a change which does a graceful stop of the threadgroup instead of a hard stop. A timeout will be added to the threadgroup waiting, to give the threads an opportunity to finish within the timeout.