S3 Storage engine (MDEV-17841)

[MDEV-19591] Assertion `!table->pos_in_locked_tables' failed in tc_release_table upon altering table into S3 under lock Created: 2019-05-24  Updated: 2019-08-23  Resolved: 2019-08-08

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Locking, Storage Engine - S3
Affects Version/s: 10.5
Fix Version/s: 10.5.0

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

Issue Links:
Duplicate
is duplicated by MDEV-17717 Assertion `!table->pos_in_locked_tabl... Closed
Relates
relates to MDEV-19416 Test S3 Storage engine Closed

 Description    

CREATE TABLE t1 (a INT);
 
LOCK TABLES t1 WRITE;
 
ALTER TABLE t1 ENGINE=S3;
 
 
 
# Cleanup
 
UNLOCK TABLES;
 
DROP TABLE t1;

10.5 0928596a

 
mysqld: /data/src/10.5/sql/table_cache.cc:466: void tc_release_table(TABLE*): Assertion `!table->pos_in_locked_tables' failed.
 
190524 22:20:09 [ERROR] mysqld got signal 6 ;
 
 
 
#6  0x00007f0ac45aee67 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x55abc50a57fa "!table->pos_in_locked_tables", file=file@entry=0x55abc50a5588 "/data/src/10.5/sql/table_cache.cc", line=line@entry=466, function=function@entry=0x55abc50a5e30 <tc_release_table(TABLE*)::__PRETTY_FUNCTION__> "void tc_release_table(TABLE*)") at assert.c:92
 
#7  0x00007f0ac45aef12 in __GI___assert_fail (assertion=0x55abc50a57fa "!table->pos_in_locked_tables", file=0x55abc50a5588 "/data/src/10.5/sql/table_cache.cc", line=466, function=0x55abc50a5e30 <tc_release_table(TABLE*)::__PRETTY_FUNCTION__> "void tc_release_table(TABLE*)") at assert.c:101
 
#8  0x000055abc4689ad8 in tc_release_table (table=0x7f0a9c1ad0a0) at /data/src/10.5/sql/table_cache.cc:466
 
#9  0x000055abc437e1c1 in close_thread_table (thd=0x7f0a9c000b10, table_ptr=0x7f0a9c000bf0) at /data/src/10.5/sql/sql_base.cc:1039
 
#10 0x000055abc4381160 in Locked_tables_list::unlink_all_closed_tables (this=0x7f0a9c004880, thd=0x7f0a9c000b10, lock=0x0, reopen_count=0) at /data/src/10.5/sql/sql_base.cc:2573
 
#11 0x000055abc4381546 in Locked_tables_list::reopen_tables (this=0x7f0a9c004880, thd=0x7f0a9c000b10, need_reopen=false) at /data/src/10.5/sql/sql_base.cc:2670
 
#12 0x000055abc4508464 in mysql_alter_table (thd=0x7f0a9c000b10, new_db=0x7f0a9c0052b8, new_name=0x7f0a9c0056c0, create_info=0x7f0ab2b7cce0, table_list=0x7f0a9c013468, alter_info=0x7f0ab2b7cc20, order_num=0, order=0x0, ignore=false) at /data/src/10.5/sql/sql_table.cc:10350
 
#13 0x000055abc45980d9 in Sql_cmd_alter_table::execute (this=0x7f0a9c013b20, thd=0x7f0a9c000b10) at /data/src/10.5/sql/sql_alter.cc:496
 
#14 0x000055abc4427743 in mysql_execute_command (thd=0x7f0a9c000b10) at /data/src/10.5/sql/sql_parse.cc:6347
 
#15 0x000055abc442ca55 in mysql_parse (thd=0x7f0a9c000b10, rawbuf=0x7f0a9c013388 "ALTER TABLE t1 ENGINE=S3", length=24, parser_state=0x7f0ab2b7e180, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:8159
 
#16 0x000055abc44180cf in dispatch_command (command=COM_QUERY, thd=0x7f0a9c000b10, packet=0x7f0a9c008321 "", packet_length=24, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1829
 
#17 0x000055abc441688d in do_command (thd=0x7f0a9c000b10) at /data/src/10.5/sql/sql_parse.cc:1362
 
#18 0x000055abc458ef13 in do_handle_one_connection (connect=0x55abc7ab0700, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1413
 
#19 0x000055abc458ec57 in handle_one_connection (arg=0x55abc7ab0700) at /data/src/10.5/sql/sql_connect.cc:1309
 
#20 0x000055abc4ec31f7 in pfs_spawn_thread (arg=0x55abc7ab0350) at /data/src/10.5/storage/perfschema/pfs.cc:1862
 
#21 0x00007f0ac698a4a4 in start_thread (arg=0x7f0ab2b7f700) at pthread_create.c:456
 
#22 0x00007f0ac466bd0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97



 Comments   
Comment by Michael Widenius [ 2019-08-08 ]

Problem was that alter table failed when it was not able to lock the S3 table with write lock (as S3 is read only).
The error handling for this case had a bug that caused the crash. The bug also affects earlier version, so the bug fix is pushed to 10.2 while the test case will be in 10.5.

Comment by Michael Widenius [ 2019-08-08 ]

This crash happens in debug builds when using LOCK TABLE together with ALTER TABLE or FLUSH TABLES and the command aborts, which causes a call to unlink_all_closed_tables()

The bug was that unlink_all_closed_tables() didn't reset thd->open_tables->pos_in_locked_tables

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