[MDEV-18068] Assertion `this == ticket->get_ctx()' failed in MDL_context::release_lock upon BACKUP STAGE END Created: 2018-12-23  Updated: 2023-05-16  Resolved: 2019-10-20

Status: Closed
Project: MariaDB Server
Component/s: Backup, Locking
Affects Version/s: 10.4
Fix Version/s: 10.4.9

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Problem/Incident
causes MDEV-20867 Perform careful review of "Server cra... Closed
is caused by MDEV-5336 Implement BACKUP STAGE for safe exter... Closed
Relates
relates to MDEV-18067 Server crash in backup_end or asserti... Closed
relates to MDEV-15481 [Draft] Server crashed in I_P_List<MD... Closed
relates to MDEV-18069 Server hang or crash in MDL_lock::inc... Closed

 Description   

Note: It's most likely the same problem as MDEV-18067, but since the assertion is different, I'm filing it separately just in case.

CREATE TABLE t1 (a INT);
 
BACKUP STAGE START;
FLUSH TABLE t1 FOR EXPORT;
UNLOCK TABLES;
 
--connect (con1,localhost,root,,test)
BACKUP STAGE START;
 
--connection default
BACKUP STAGE END;
 
# Cleanup
--connection con1
BACKUP STAGE END;
--disconnect con1
--connection default
DROP TABLE t1;

10.4 a8eb0c76b debug

mysqld: /data/src/10.4/sql/mdl.cc:2831: void MDL_context::release_lock(enum_mdl_duration, MDL_ticket*): Assertion `this == ticket->get_ctx()' failed.
181224 17:51:49 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f64df92bee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x000055b996bd8c74 in MDL_context::release_lock (this=0x7f64c8000c20, duration=MDL_EXPLICIT, ticket=0x7f64bc01ac90) at /data/src/10.4/sql/mdl.cc:2831
#9  0x000055b996bd8d63 in MDL_context::release_lock (this=0x7f64c8000c20, ticket=0x7f64bc01ac90) at /data/src/10.4/sql/mdl.cc:2853
#10 0x000055b996cadedb in backup_end (thd=0x7f64c8000b00) at /data/src/10.4/sql/backup.cc:308
#11 0x000055b996cad894 in run_backup_stage (thd=0x7f64c8000b00, stage=BACKUP_END) at /data/src/10.4/sql/backup.cc:119
#12 0x000055b996a6b94b in mysql_execute_command (thd=0x7f64c8000b00) at /data/src/10.4/sql/sql_parse.cc:5233
#13 0x000055b996a748e4 in mysql_parse (thd=0x7f64c8000b00, rawbuf=0x7f64c8014f98 "BACKUP STAGE END", length=16, parser_state=0x7f64d9abd600, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8104
#14 0x000055b996a61b0e in dispatch_command (command=COM_QUERY, thd=0x7f64c8000b00, packet=0x7f64c800b421 "BACKUP STAGE END", packet_length=16, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1851
#15 0x000055b996a60532 in do_command (thd=0x7f64c8000b00) at /data/src/10.4/sql/sql_parse.cc:1396
#16 0x000055b996bcc6de in do_handle_one_connection (connect=0x55b9993c06a0) at /data/src/10.4/sql/sql_connect.cc:1402
#17 0x000055b996bcc462 in handle_one_connection (arg=0x55b9993c06a0) at /data/src/10.4/sql/sql_connect.cc:1308
#18 0x000055b99708b338 in pfs_spawn_thread (arg=0x55b999304960) at /data/src/10.4/storage/perfschema/pfs.cc:1862
#19 0x00007f64e13e7494 in start_thread (arg=0x7f64d9abe700) at pthread_create.c:333
#20 0x00007f64df9e893f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Non-debug build produces the same SIGSEGV as MDEV-18087:

10.4 a8eb0c76b non-debug

#5  <signal handler called>
#6  0x0000000000000055 in ?? ()
#7  0x0000558f1155a24f in backup_end (thd=0x7f9db00009a8) at /data/src/10.4/sql/backup.cc:308
#8  0x0000558f1155a2d8 in run_backup_stage (thd=0x7f9db00009a8, stage=BACKUP_END) at /data/src/10.4/sql/backup.cc:119
#9  0x0000558f113f4399 in mysql_execute_command (thd=0x7f9db00009a8) at /data/src/10.4/sql/sql_parse.cc:5233
#10 0x0000558f113fa9a1 in mysql_parse (thd=0x7f9db00009a8, rawbuf=<optimized out>, length=16, parser_state=0x7f9dccc9d640, is_com_multi=<optimized out>, is_next_command=<optimized out>) at /data/src/10.4/sql/sql_parse.cc:8104
#11 0x0000558f113fd315 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x7f9db00009a8, packet=packet@entry=0x7f9db0009559 "BACKUP STAGE END", packet_length=packet_length@entry=16, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/src/10.4/sql/sql_parse.cc:1851
#12 0x0000558f113fdca0 in do_command (thd=0x7f9db00009a8) at /data/src/10.4/sql/sql_parse.cc:1396
#13 0x0000558f114cfd54 in do_handle_one_connection (connect=connect@entry=0x558f149900c8) at /data/src/10.4/sql/sql_connect.cc:1402
#14 0x0000558f114cfef4 in handle_one_connection (arg=arg@entry=0x558f149900c8) at /data/src/10.4/sql/sql_connect.cc:1308
#15 0x0000558f117c65a4 in pfs_spawn_thread (arg=0x558f14990668) at /data/src/10.4/storage/perfschema/pfs.cc:1862
#16 0x00007f9dd4613494 in start_thread (arg=0x7f9dccc9e700) at pthread_create.c:333
#17 0x00007f9dd2c1493f in clone () from /lib/x86_64-linux-gnu/libc.so.6



 Comments   
Comment by Michael Widenius [ 2019-10-20 ]

The problem was that "FLUSH TABLES table_name" combined with UNLOCK TABLES
calls MDL_context::set_transaction_duration_for_all_locks(), which
changed backup_locks from MDL_EXPLICT to MDL_TRANSACTION.

Fixed by ensuring that set_transaction_duration_for_all_locks() doesn't
touch BACKUP locks.

Generated at Thu Feb 08 08:41:16 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.