[MDEV-18088] Assertion `share->in_trans == 0' failed in maria_close upon double ALTER under lock Created: 2018-12-26  Updated: 2020-03-04  Resolved: 2020-02-27

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Locking, Storage Engine - Aria
Affects Version/s: 10.2, 10.3, 10.4
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: affects-tests

Issue Links:
Duplicate
duplicates MDEV-10748 Server crashes in ha_maria::implicit_... Closed
Relates
relates to MDEV-21830 Server crash in ha_maria::implicit_co... Confirmed
relates to MDEV-21754 Assertion `file->trn == trn' failed i... Closed
relates to MDEV-21755 Assertion `0' failed in add_to_locked... Closed

 Description   

CREATE TABLE t1 (a INT) ENGINE=Aria;
CREATE TABLE t2 (b INT) ENGINE=Aria;
 
LOCK TABLE t1 WRITE, t2 WRITE;
ALTER TABLE t1 MODIFY a CHAR(1), CHANGE a c INT;
 
# Cleanup
DROP TABLE t1, t2;

10.2 734029fa7

mysqld: /data/src/10.2/storage/maria/ma_close.c:99: maria_close: Assertion `share->in_trans == 0' failed.
181227  0:57:11 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f0d3b408ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x0000564182c1278e in maria_close (info=0x7f0d24034420) at /data/src/10.2/storage/maria/ma_close.c:99
#9  0x0000564182b8e19c in ha_maria::close (this=0x7f0d240098b8) at /data/src/10.2/storage/maria/ha_maria.cc:1274
#10 0x0000564182988ca7 in handler::ha_close (this=0x7f0d240098b8) at /data/src/10.2/sql/handler.cc:2567
#11 0x000056418280fefc in closefrm (table=0x7f0d24170960) at /data/src/10.2/sql/table.cc:3448
#12 0x00005641828faeb1 in intern_close_table (table=0x7f0d24170960) at /data/src/10.2/sql/table_cache.cc:222
#13 0x00005641828fb050 in tc_remove_table (table=0x7f0d24170960) at /data/src/10.2/sql/table_cache.cc:260
#14 0x00005641828fb899 in tc_release_table (table=0x7f0d24170960) at /data/src/10.2/sql/table_cache.cc:461
#15 0x0000564182694f28 in close_thread_table (thd=0x7f0d24000b00, table_ptr=0x7f0d24039d30) at /data/src/10.2/sql/sql_base.cc:903
#16 0x0000564182694872 in close_all_tables_for_name (thd=0x7f0d24000b00, share=0x7f0d2400c238, extra=HA_EXTRA_NOT_USED, skip_table=0x1) at /data/src/10.2/sql/sql_base.cc:677
#17 0x0000564182697b70 in Locked_tables_list::reopen_tables (this=0x7f0d24004550, thd=0x7f0d24000b00, need_reopen=true) at /data/src/10.2/sql/sql_base.cc:2422
#18 0x0000564182712ab3 in mysql_execute_command (thd=0x7f0d24000b00) at /data/src/10.2/sql/sql_parse.cc:6257
#19 0x00005641827177f7 in mysql_parse (thd=0x7f0d24000b00, rawbuf=0x7f0d24012448 "ALTER TABLE t1 MODIFY a CHAR(1), CHANGE a c INT", length=47, parser_state=0x7f0d356e4200, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:8014
#20 0x000056418270512f in dispatch_command (command=COM_QUERY, thd=0x7f0d24000b00, packet=0x7f0d2408c471 "ALTER TABLE t1 MODIFY a CHAR(1), CHANGE a c INT", packet_length=47, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1825
#21 0x0000564182703a92 in do_command (thd=0x7f0d24000b00) at /data/src/10.2/sql/sql_parse.cc:1379
#22 0x0000564182856569 in do_handle_one_connection (connect=0x564185a399e0) at /data/src/10.2/sql/sql_connect.cc:1335
#23 0x00005641828562f6 in handle_one_connection (arg=0x564185a399e0) at /data/src/10.2/sql/sql_connect.cc:1241
#24 0x0000564182c7c230 in pfs_spawn_thread (arg=0x56418599d050) at /data/src/10.2/storage/perfschema/pfs.cc:1862
#25 0x00007f0d3cec4494 in start_thread (arg=0x7f0d356e5700) at pthread_create.c:333
#26 0x00007f0d3b4c593f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Not reproducible on 10.1.
No visible effect on a non-debug build, apart from the generic ER_BAD_FIELD_ERROR (Unknown column 'a' in 't1') (https://bugs.mysql.com/bug.php?id=3394).



 Comments   
Comment by Elena Stepanova [ 2020-02-27 ]

The assertion failure stopped happening on 10.2 (and then higher versions) after this commit:

commit 7952f7720f967b43873e4fac13583984803fae3b
Author: Monty
Date:   Tue Oct 15 20:26:40 2019 +0300
 
    MDEV-10748 Server crashes in ha_maria::implicit_commit
    
    Problem was in a combination of LOCK TABLES on several Aria
    tables followed by an ALTER TABLE. After the ALTER TABLE there
    was a force close + reopen of the alter table. The close failed
    because the table was still part of a transaction.
    
    Fixed by calling extra(HA_EXTRA_PREPARE_FOR_FORCED_CLOSE) as
    part of closing the table, which ensures that the table is not
    anymore part of the current transaction.

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