Application verifier reports an error in plugins_var test (recursive read lock on reader writer lock) for LOCK_system_variables_hash.
The lock is acquired in sql_show.cc , in fill_variables() function
however the same lock is acquired again deeper inside show_status array. appverifier points to this callstack
On Windows, recursive shared lock acquire can cause a deadlock. Here is the explanation of the bug given by windbg command '!analyze -v'
The SRW lock is being acquired recursively by the same thread.
This stop is generated if the SRW lock (Param1) is being acquired
recursively by the same thread.
This will result in a deadlock and the thread would block indefinitely.
Recursive acquisition of an SRW lock in exclusive mode will cause a deadlock.
Recursive acquisition of an SRW lock in shared mode will cause a deadlock when
there is a thread waiting for exclusive access. Consider the example below:
- Thread A acquires the SRW lock in shared mode
- Thread B tries to acruire the SRW lock in exclusive mode and waits
- Thread A tries to acquire the SRW lock in shared mode recursively. This will
be successful as long as there is no exclusive waiter (in this case B). Since
SRW locks do not have writer starvation, thread A waits behind thread B.
Now, Thread B is waiting for Thread A which is inturn waiting for Thread B
causing a circular wait and hence a deadlock.