virtual void MYSQL_BIN_LOG::xlock(): Assertion `!snapshot_lock_acquired' failed in sql/binlog.cc:7566
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS |
Fix Released
|
High
|
Yura Sorokin | ||
5.1 |
Invalid
|
Undecided
|
Unassigned | ||
5.5 |
Invalid
|
Undecided
|
Unassigned | ||
5.6 |
Fix Released
|
High
|
Yura Sorokin |
Bug Description
** Testcase
SET @@global.
START TRANSACTION READ ONLY, WITH CONSISTENT SNAPSHOT; ;
To reproduce the issue we need to run multi thread pquery binary. The attached tarball gives the testcase as an exact match of our system, including some handy utilities
$ vi {epoch}_mybase # Update base path in this file (the only change
required!)
$ ./{epoch}_init # Initializes the data dir
$ ./{epoch}_start # Starts mysqld
$ ./{epoch}_cl # To check mysqld is up
$ ./{epoch}
output)
$ vi /dev/shm/
$ ./{epoch}_gdb # Brings you to a gdb prompt attached to correct
mysqld
& generated core
$ ./{epoch}
standard and full var gdb stack traces
etc.
** Startup
--innodb_
** GDB info
#0 0x00007f21ec01b5c9 in raise () from /lib64/libc.so.6
#1 0x00007f21ec01ccd8 in abort () from /lib64/libc.so.6
#2 0x00007f21ec014536 in __assert_fail_base () from /lib64/libc.so.6
#3 0x00007f21ec0145e2 in __assert_fail () from /lib64/libc.so.6
#4 0x0000000000a4deb4 in MYSQL_BIN_
#5 0x0000000000641838 in ha_start_
#6 0x00000000008b80af in trans_begin (thd=0x7f21d4b1
#7 0x00000000007e87c9 in mysql_execute_
#8 0x00000000007edf41 in mysql_parse (thd=0x7f21d4b1
#9 0x00000000007dfdb7 in dispatch_command (command=COM_QUERY, thd=0x7f21d4b17000, packet=
#10 0x00000000007decd5 in do_command (thd=0x7f21d4b1
#11 0x00000000007a6c4d in do_handle_
#12 0x00000000007a6755 in handle_
#13 0x0000000000dc9e6c in pfs_spawn_thread (arg=0x7f21e6b4
#14 0x00007f21ed412df3 in start_thread () from /lib64/
#15 0x00007f21ec0dc1ad in clone () from /lib64/libc.so.6
(gdb) +set logging off
no longer affects: | percona-server/5.5 |
no longer affects: | percona-server/5.1 |
Although I did not manage to reproduce this on 5.6 (commit f3f9359). The potential problem seems to be with the following method in "binlog.cc".
void MYSQL_BIN_ LOG::xlock( void) ASSERT( !snapshot_ lock_acquired) ;
{
DBUG_
mysql_ mutex_lock( &LOCK_log) ;
if (opt_binlog_ order_commits) mutex_lock( &LOCK_commit) ; lock_acquired= true; rwlock_ wrlock( &LOCK_consisten t_snapshot) ;
{
mysql_
}
else
{
snapshot_
mysql_
}
}
One thread may successfully call "xlock()" and set "snapshot_ lock_acquired" to "true" whereas another one may call the same "xlock()" method and end up in "DBUG_ASSERT( !snapshot_ lock_acquired) ;" assertion.
The fix would be in putting "DBUG_ASSERT( !snapshot_ lock_acquired) ;" after "mysql_ mutex_lock( &LOCK_log) ;"