BUG#26502135: MYSQLD SEGFAULTS IN
MDL_CONTEXT::TRY_ACQUIRE_LOCK_IMPL ANALYSIS: ========= Server sometimes exited when multiple threads tried to acquire and release metadata locks simultaneously (for example, necessary to access a table). The same problem could have occurred when new objects were registered/ deregistered in Performance Schema. The problem was caused by a bug in LF_HASH - our lock free hash implementation which is used by metadata locking subsystem in 5.7 branch. In 5.5 and 5.6 we only use LF_HASH in Performance Schema Instrumentation implementation. So for these versions, the problem was limited to P_S. The problem was in my_lfind() function, which searches for the specific hash element by going through the elements list. During this search it loads information about element checked such as key pointer and hash value into local variables. Then it confirms that they are not corrupted by concurrent delete operation (which will set pointer to 0) by checking if element is still in the list. The latter check did not take into account that compiler (and processor) can reorder reads in such a way that load of key pointer will happen after it, making result of the check invalid. FIX: ==== This patch fixes the problem by ensuring that no such reordering can take place. This is achieved by using my_atomic_loadptr() which contains compiler and processor memory barriers for the check mentioned above and other similar places. The default (for non-Windows systems) implementation of my_atomic*() relies on old __sync intrisics and implements my_atomic_loadptr() as read-modify operation. To avoid scalability/performance penalty associated with addition of my_atomic_loadptr()'s we change the my_atomic*() to use newer __atomic intrisics when available. This new default implementation doesn't have such a drawback.
Showing
Please register or sign in to comment