![](https://secure.gravatar.com/avatar/99fde0c1dfd216326aae0aff30d493f1.jpg?s=120&d=mm&r=g)
Pavel Ivanov
sql/log.cc has highly inconsistent pattern of accessing rpl_global_gtid_binlog_state. In some places it's protected by mutex rpl_global_gtid_binlog_state.LOCK_binlog_state, in some places it's protected by global mutex LOCK_rpl_gtid_state, and in some places it's not protected by any mutex at all. This is a bug that should be fixed, right?
Yes, agree, thanks for finding this.
I can file this in JIRA if you want, just wanted to let you know faster.
I've filed it as MDEV-5306.
I've noticed this problem after one of our AddressSanitizer testing bots reported that rpl_binlog_state::bump_seq_no_if_needed (called from MYSQL_BIN_LOG::bump_seq_no_counter_if_needed) was using memory from hash after it was already freed by rpl_binlog_state::reset (called by MYSQL_BIN_LOG::reset_logs).
Can you test again with the latest patch I've just pushed to 10.0-base? I looked briefly into making an mtr test case to catch this, but I did not see any easy way to do that. I went through the code to try and check all uses of rpl_binlog_state for proper locking, but it would be nice to get a confirmation that I did not miss anything. - Kristian.