BUG#26502135: MYSQLD SEGFAULTS IN MDL_CONTEXT::TRY_ACQUIRE_LOCK_IMPL

被坑了一把，mysql 5.7版本引入LF_HASH来用于MDL子系统，在频繁进行申请和释放metadata lock时数据库可能会crash,

函数堆栈最底层为lf_hash_search，该bug在mysql 5.7.22及以上版本修复。

BUG#26502135: MYSQLD SEGFAULTS IN MDL_CONTEXT::TRY_ACQUIRE_LOCK_IMPL

ANALYSIS:

=========

Server sometimes exited when multiple threads tried toacquire and release metadata locks

simultaneously (forexample, 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 lockingsubsystem 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 (andprocessor) can reorder reads in such

a way that load of key pointer will happen after it, making result of the checkinvalid.

FIX:

====

This patch fixes the problem by ensuring that no such reordering can take place.

This is achieved by usingmy_atomic_loadptr() which contains compiler and processor

memory barriers for the check mentioned above and othersimilar places.

The default (for non-Windows systems) implementation of my_atomic*() relies on old __sync

intrisics and implementsmy_atomic_loadptr() as read-modify operation. To avoid scalability/performance penalty associated with addition ofmy_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.