[MDEV-20518] BACKUP STAGE: Assertion `share->now_transactional == share->base.born_transactional' failed in maria_close Created: 2019-09-06  Updated: 2023-01-20

Status: Stalled
Project: MariaDB Server
Component/s: Backup, Storage Engine - Aria
Affects Version/s: 10.5
Fix Version/s: 10.5

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

Issue Links:
Blocks
Relates
relates to MDEV-14865 Assertion `share->now_transactional =... Stalled

 Description   

Note: The assertion failure is the same as in MDEV-14865, but the test case appears to be specific to backup stages, so I'm filing it separately.

The test case is non-deterministic, run with --repeat=N. It always fails for me within 3 attempts, but it can vary on different machines and builds.

--connect (con1,localhost,root,,test)
CREATE TABLE t1 (a INT) ENGINE=Aria;
 
--connection default
BACKUP STAGE START;
 
--connect (con2,localhost,root,,test)
--send
    CHECK TABLE t1 EXTENDED;
 
--connection default
CHECK TABLE t1 EXTENDED;
BACKUP STAGE BLOCK_COMMIT;
 
# Cleanup
--connection con2
--reap
--disconnect con2
--disconnect con1
--connection default
BACKUP STAGE END;
DROP TABLE t1;

10.5 db9e41dd debug

mysqld: /data/src/10.5/storage/maria/ma_close.c:176: maria_close: Assertion `share->now_transactional == share->base.born_transactional' failed.
190906 21:24:59 [ERROR] mysqld got signal 6 ;
 
#7  0x00007ff4d9a75f12 in __GI___assert_fail (assertion=0x5607fd723b18 "share->now_transactional == share->base.born_transactional", file=0x5607fd723918 "/data/src/10.5/storage/maria/ma_close.c", line=176, function=0x5607fd723b90 <__PRETTY_FUNCTION__.15384> "maria_close") at assert.c:101
#8  0x00005607fcef13bc in maria_close (info=0x7ff4b0023b20) at /data/src/10.5/storage/maria/ma_close.c:176
#9  0x00005607fce64361 in ha_maria::close (this=0x7ff4b001bbf8) at /data/src/10.5/storage/maria/ha_maria.cc:1227
#10 0x00005607fcc1a6f6 in handler::ha_close (this=0x7ff4b001bbf8) at /data/src/10.5/sql/handler.cc:2783
#11 0x00005607fca26f21 in closefrm (table=0x7ff4b001a920) at /data/src/10.5/sql/table.cc:4097
#12 0x00005607fcb49e43 in intern_close_table (table=0x7ff4b001a920) at /data/src/10.5/sql/table_cache.cc:222
#13 0x00005607fcb4a268 in tc_purge (mark_flushed=false) at /data/src/10.5/sql/table_cache.cc:335
#14 0x00005607fcb545d4 in backup_flush (thd=0x7ff4b8000b10) at /data/src/10.5/sql/backup.cc:207
#15 0x00005607fcb5425e in run_backup_stage (thd=0x7ff4b8000b10, stage=BACKUP_LOCK_COMMIT) at /data/src/10.5/sql/backup.cc:110
#16 0x00005607fc8f8cd8 in mysql_execute_command (thd=0x7ff4b8000b10) at /data/src/10.5/sql/sql_parse.cc:4990
#17 0x00005607fc902b37 in mysql_parse (thd=0x7ff4b8000b10, rawbuf=0x7ff4b80133a8 "BACKUP STAGE BLOCK_COMMIT", length=25, parser_state=0x7ff4d4449580, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:7934
#18 0x00005607fc8ef121 in dispatch_command (command=COM_QUERY, thd=0x7ff4b8000b10, packet=0x7ff4b8137241 "BACKUP STAGE BLOCK_COMMIT", packet_length=25, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1847
#19 0x00005607fc8ed934 in do_command (thd=0x7ff4b8000b10) at /data/src/10.5/sql/sql_parse.cc:1364
#20 0x00005607fca7ce7c in do_handle_one_connection (connect=0x56080056bcb0, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1414
#21 0x00005607fca7cbab in handle_one_connection (arg=0x560800458490) at /data/src/10.5/sql/sql_connect.cc:1309
#22 0x00005607fcf81343 in pfs_spawn_thread (arg=0x5608004580f0) at /data/src/10.5/storage/perfschema/pfs.cc:1862
#23 0x00007ff4db5ea4a4 in start_thread (arg=0x7ff4d444a700) at pthread_create.c:456
#24 0x00007ff4d9b32d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

No obvious effect on a non-debug build.


Generated at Thu Feb 08 09:00:05 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.