[MDEV-10130] Assertion `share->in_trans == 0' failed in storage/maria/ma_close.c Created: 2016-05-26  Updated: 2018-05-24  Resolved: 2018-05-23

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - Aria
Affects Version/s: 10.0, 10.1, 10.2
Fix Version/s: 10.0.36, 10.1.34, 10.2.16, 10.3.8

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

Issue Links:
Duplicate
is duplicated by MDEV-14669 Assertion `file->trn == trn' failed i... Closed
PartOf
includes MDEV-10378 Assertion `trn' failed in virtual int... Closed

 Description   

Test case

--source include/have_innodb.inc
 
CREATE TABLE IF NOT EXISTS `t_ar` (`i` INT) ENGINE=Aria;
CREATE TABLE IF NOT EXISTS `t_in` (`i` INT) ENGINE=InnoDB;
 
--delimiter |
CREATE PROCEDURE pr() 
BEGIN
    DECLARE abiss INT DEFAULT 0;
    LOOP
        SELECT * FROM ( SELECT al1.* FROM `t_in` AS al1 LEFT JOIN `t_ar` AS al2 ON ( al1.`i` = al2.`i` AND al1.`i` = ( SELECT COUNT(*) FROM `t_ar` al3 INNER JOIN `t_ar` al4 ON (al3.`i` = al4.`i` ) ) ) ) AS sq INTO abiss;
    END LOOP;
END |
--delimiter ;
 
--connect (con1,localhost,root,,)
--send CALL pr()
 
--connection default
 
--let $run = 10000
 
while ($run) {
    ANALYZE TABLE `t_ar`, `t_in`;
    --dec $run
}
 
--connection con1
--reap
--disconnect con1
 
--connection default
DROP PROCEDURE pr;
DROP TABLE t_in, t_ar;

Stack trace from 10.0 commit 732e2694058788c14b55db052dedc102ac21d1bc

mysqld: /src/10.0/storage/maria/ma_close.c:96: maria_close: Assertion `share->in_trans == 0' failed.
160611 17:49:30 [ERROR] mysqld got signal 6 ;
 
#7  0x00007f4cc11331d2 in __assert_fail () from /lib64/libc.so.6
#8  0x0000000000d2070e in maria_close (info=0x7f4cae568730) at /src/10.0/storage/maria/ma_close.c:96
#9  0x0000000000ca5230 in ha_maria::close (this=0x7f4cae4b9088) at /src/10.0/storage/maria/ha_maria.cc:1264
#10 0x00000000008610dd in handler::ha_close (this=0x7f4cae4b9088) at /src/10.0/sql/handler.cc:2586
#11 0x000000000074a0ab in closefrm (table=0x7f4cae43ac70, free_share=true) at /src/10.0/sql/table.cc:2957
#12 0x000000000060869e in intern_close_table (table=0x7f4cae43ac70) at /src/10.0/sql/sql_base.cc:337
#13 0x00000000007ed964 in tc_release_table (table=0x7f4cae43ac70) at /src/10.0/sql/table_cache.cc:408
#14 0x0000000000609c7f in close_thread_table (thd=0x7f4cbaf6ebf0, table_ptr=0x7f4cbaf6ecb0) at /src/10.0/sql/sql_base.cc:1057
#15 0x00000000006094a7 in close_open_tables (thd=0x7f4cbaf6ebf0) at /src/10.0/sql/sql_base.cc:780
#16 0x0000000000609a0b in close_thread_tables (thd=0x7f4cbaf6ebf0) at /src/10.0/sql/sql_base.cc:1004
#17 0x00000000006745d9 in mysql_execute_command (thd=0x7f4cbaf6ebf0) at /src/10.0/sql/sql_parse.cc:5167
#18 0x000000000099cfee in sp_instr_stmt::exec_core (this=0x7f4cae8303f8, thd=0x7f4cbaf6ebf0, nextp=0x7f4cc3191a08) at /src/10.0/sql/sp_head.cc:3204
#19 0x000000000099c73d in sp_lex_keeper::reset_lex_and_exec_core (this=0x7f4cae830438, thd=0x7f4cbaf6ebf0, nextp=0x7f4cc3191a08, open_tables=false, instr=0x7f4cae8303f8) at /src/10.0/sql/sp_head.cc:2971
#20 0x000000000099ccf6 in sp_instr_stmt::execute (this=0x7f4cae8303f8, thd=0x7f4cbaf6ebf0, nextp=0x7f4cc3191a08) at /src/10.0/sql/sp_head.cc:3120
#21 0x0000000000998b3d in sp_head::execute (this=0x7f4cae824888, thd=0x7f4cbaf6ebf0, merge_da_on_success=true) at /src/10.0/sql/sp_head.cc:1371
#22 0x000000000099a7d7 in sp_head::execute_procedure (this=0x7f4cae824888, thd=0x7f4cbaf6ebf0, args=0x7f4cbaf731f0) at /src/10.0/sql/sp_head.cc:2159
#23 0x000000000067308b in mysql_execute_command (thd=0x7f4cbaf6ebf0) at /src/10.0/sql/sql_parse.cc:4720
#24 0x00000000006777cd in mysql_parse (thd=0x7f4cbaf6ebf0, rawbuf=0x7f4cae822088 "CALL pr()", length=9, parser_state=0x7f4cc3192650) at /src/10.0/sql/sql_parse.cc:6574
#25 0x000000000066a309 in dispatch_command (command=COM_QUERY, thd=0x7f4cbaf6ebf0, packet=0x7f4cbaf7f871 "CALL pr()", packet_length=9) at /src/10.0/sql/sql_parse.cc:1308
#26 0x00000000006695d6 in do_command (thd=0x7f4cbaf6ebf0) at /src/10.0/sql/sql_parse.cc:998
#27 0x0000000000787cb2 in do_handle_one_connection (thd_arg=0x7f4cbaf6ebf0) at /src/10.0/sql/sql_connect.cc:1378
#28 0x0000000000787a24 in handle_one_connection (arg=0x7f4cbaf6ebf0) at /src/10.0/sql/sql_connect.cc:1293
#29 0x0000000000df561c in pfs_spawn_thread (arg=0x7f4cbaeade70) at /src/10.0/storage/perfschema/pfs.cc:1860
#30 0x00007f4cc2e560a4 in start_thread () from /lib64/libpthread.so.0



 Comments   
Comment by Michael Widenius [ 2018-05-21 ]

The problem was that maria_handler->trn was not properly reset
at commit/rollback and ha_maria::exernal_lock() could get confused
because.

There was some old code in ha_maria::implicit_commit() that tried
to take care of this, but it was not bullet proof.

Fixed by adding list of all tables that is part of the maria transaction to
TRN.

Comment by Michael Widenius [ 2018-05-23 ]

rebasing and testing

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