[MDEV-4233] Galera: assertion: (lock->trx)->wait_lock == lock fails in file lock0lock.c line 796 Created: 2013-03-03  Updated: 2016-08-11  Resolved: 2013-11-26

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 5.5.28a-galera
Fix Version/s: 5.5.34-galera

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Jan Lindström (Inactive)
Resolution: Fixed Votes: 0
Labels: galera

Issue Links:
Relates
relates to MDEV-10544 Galera: Failing assertion: (lock->tr... Closed

 Description   

InnoDB: Assertion failure in thread 140591255873280 in file lock0lock.c line 796
InnoDB: Failing assertion: (lock->trx)->wait_lock == lock
InnoDB: We intentionally generate a memory trap.

#5  0x00007fde22463b0b in __GI_abort () at abort.c:92
#6  0x0000000000baae73 in lock_reset_lock_and_trx_wait (lock=0x4d3ac40) at maria-5.5-galera/storage/xtradb/lock/lock0lock.c:796
#7  0x0000000000badfff in lock_grant (lock=0x4d3ac40) at maria-5.5-galera/storage/xtradb/lock/lock0lock.c:2362
#8  0x0000000000bb1cad in lock_table_dequeue (in_lock=0x7fde100a9d50) at maria-5.5-galera/storage/xtradb/lock/lock0lock.c:4299
#9  0x0000000000bb2186 in lock_cancel_waiting_and_release (lock=0x7fde100a9d50) at maria-5.5-galera/storage/xtradb/lock/lock0lock.c:4458
#10 0x0000000000bb0eb2 in lock_table_create (c_lock=0x7fde100a9d50, table=0x4a1a918, type_mode=257, trx=0x4a8ad78) at maria-5.5-galera/storage/xtradb/lock/lock0lock.c:3853
#11 0x0000000000bb1622 in lock_table_enqueue_waiting (c_lock=0x7fde100a9d50, mode=1, table=0x4a1a918, thr=0x4b59e48) at maria-5.5-galera/storage/xtradb/lock/lock0lock.c:4054
#12 0x0000000000bb1a5a in lock_table (flags=0, table=0x4a1a918, mode=LOCK_IX, thr=0x4b59e48) at maria-5.5-galera/storage/xtradb/lock/lock0lock.c:4214
#13 0x0000000000c0d44e in row_ins_step (thr=0x4b59e48) at maria-5.5-galera/storage/xtradb/row/row0ins.c:2633
#14 0x0000000000a7ff4d in row_insert_for_mysql (mysql_rec=0x4d838b8 "\377\377O", prebuilt=0x4b594b8) at maria-5.5-galera/storage/xtradb/row/row0mysql.c:1256
#15 0x0000000000a44390 in ha_innobase::write_row (this=0x4adb158, record=0x4d838b8 "\377\377O") at maria-5.5-galera/storage/xtradb/handler/ha_innodb.cc:6599
#16 0x00000000007f0107 in handler::ha_write_row (this=0x4adb158, buf=0x4d838b8 "\377\377O") at maria-5.5-galera/sql/handler.cc:5232
#17 0x00000000005fdc67 in write_record (thd=0x499c8a0, table=0x4b58af0, info=0x7fddf3dd46a0) at maria-5.5-galera/sql/sql_insert.cc:1854
#18 0x00000000005fb870 in mysql_insert (thd=0x499c8a0, table_list=0x4ce3370, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR, ignore=false) at maria-5.5-galera/sql/sql_insert.cc:995
#19 0x000000000061b5eb in mysql_execute_command (thd=0x499c8a0) at maria-5.5-galera/sql/sql_parse.cc:3244
#20 0x0000000000625224 in mysql_parse (thd=0x499c8a0, rawbuf=0x4ce3268 "INSERT INTO `AA` ( `pk` ) VALUES ( NULL )", length=41, parser_state=0x7fddf3dd5550) at maria-5.5-galera/sql/sql_parse.cc:6305
#21 0x00000000006242ea in wsrep_mysql_parse (thd=0x499c8a0, rawbuf=0x4ce3268 "INSERT INTO `AA` ( `pk` ) VALUES ( NULL )", length=41, parser_state=0x7fddf3dd5550) at maria-5.5-galera/sql/sql_parse.cc:6070
#22 0x00000000006167b9 in dispatch_command (command=COM_QUERY, thd=0x499c8a0, packet=0x4a90d61 "INSERT INTO `AA` ( `pk` ) VALUES ( NULL )", packet_length=41) at maria-5.5-galera/sql/sql_parse.cc:1245
#23 0x0000000000615598 in do_command (thd=0x499c8a0) at maria-5.5-galera/sql/sql_parse.cc:891
#24 0x000000000071e143 in do_handle_one_connection (thd_arg=0x499c8a0) at maria-5.5-galera/sql/sql_connect.cc:1291
#25 0x000000000071db1b in handle_one_connection (arg=0x499c8a0) at maria-5.5-galera/sql/sql_connect.cc:1199
#26 0x00007fde22d5fefc in start_thread (arg=0x7fddf3dd6700) at pthread_create.c:304
#27 0x00007fde2250ef4d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x4ce3268): INSERT INTO `AA` ( `pk` ) VALUES ( NULL )
Connection ID (thread ID): 7
Status: NOT_KILLED

I run a single Galera node, server command line:

$HOME/maria-5.5-galera/sql/mysqld --no-defaults --basedir=$HOME/maria-5.5-galera --lc-messages-dir=$HOME/maria-5.5-galera/sql/share/ --core --datadir=$HOME/maria-5.5-galera/data1 --tmpdir=$HOME/maria-5.5-galera/data1/tmp --port=8306 --socket=$HOME/maria-5.5-galera/data1/tmp/node1.sock --wsrep-provider=$HOME/galera/libgalera_smm.so --wsrep-cluster-address=gcomm:// --binlog-format=row --wsrep-sst-method=rsync --log-error=$HOME/maria-5.5-galera/data1/log.err --innodb_autoinc_lock_mode=2 --innodb_locks_unsafe_for_binlog=1

Same happens with wsrep not enabled:

$HOME/maria-5.5-galera/sql/mysqld --no-defaults --basedir=$HOME/maria-5.5-galera --lc-messages-dir=$HOME/maria-5.5-galera/sql/share/ --core --datadir=$HOME/maria-5.5-galera/data1 --tmpdir=$HOME/maria-5.5-galera/data1/tmp --port=8306 --socket=$HOME/maria-5.5-galera/data1/tmp/node1.sock   --binlog-format=row  --log-error=$HOME/maria-5.5-galera/data1/log.err --innodb_autoinc_lock_mode=2 --innodb_locks_unsafe_for_binlog=1

RQG grammar (test.yy):

query_init:
  SET AUTOCOMMIT = OFF ; SET @@lock_wait_timeout = 2 ; SET @@innodb_lock_wait_timeout = 1 ;
 
query:
	binlog_event | binlog_event | binlog_event | binlog_event | binlog_event | trigger ;
 
binlog_event:
	delete | insert | lock ;
 
lock:
	LOCK TABLE _table WRITE ; UNLOCK TABLES ;
 
insert:
	INSERT INTO _table ( _field ) VALUES ( NULL ) ;
 
delete:
	DELETE FROM _table LIMIT 1 ;
 
trigger:
	CREATE TRIGGER _letter trigger_time trigger_event ON _table FOR EACH ROW BEGIN binlog_event ; END ;
 
trigger_time:
        BEFORE | AFTER ;
 
trigger_event:
        INSERT | UPDATE ;

RQG command line:

perl gentest.pl --dsn=dbi:mysql:host=127.0.0.1:port=8306:user=root:database=test --queries=100M --duration=300 --engine=InnoDB --grammar=test.yy --gendata --threads=2

revision-id: daniel@gandalf-20130301022556-h2fqksol83zg35b2
revno: 3386
branch-nick: maria-5.5-galera

Built as cmake . -DCMAKE_BUILD_TYPE=Debug && make



 Comments   
Comment by Jan Lindström (Inactive) [ 2013-11-26 ]

Fix works!

Generated at Thu Feb 08 06:54:49 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.