[MDEV-20306] Assertion `!(end_of_data > info->scan.dir_end)' failed in _ma_scan_block_record upon converting table from S3 to Aria with encryption enabled Created: 2019-08-09  Updated: 2023-12-05

Status: Stalled
Project: MariaDB Server
Component/s: Encryption, Storage Engine - Aria, Storage Engine - S3
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:
Relates
relates to MDEV-17841 S3 Storage engine Closed

 Description   

Remember to run with all usual S3 options and also with

--mysqld=--aria-encrypt-tables=1  --mysqld=--file-key-management --mysqld=--file-key-management-filename=`pwd`/std_data/keys.txt --mysqld=--plugin-load-add=file_key_management

Also remember to clean up the bucket between attempts.

CREATE TABLE t1 (a INT) ENGINE=Aria;
 
INSERT INTO t1 VALUES (1);
 
ALTER TABLE t1 ENGINE=S3;
 
ALTER TABLE t1 ENGINE=Aria;
 
 
 
# Cleanup
 
DROP TABLE t1;

On a non-debug build, the second ALTER causes ER_CRASHED_ON_USAGE:

10.5 46553c25 non-debug

 
mysqltest: At line 4: query 'ALTER TABLE t1 ENGINE=Aria' failed: 1194: Table 't1' is marked as crashed and should be repaired

On a debug build, it causes the assertion failure:

10.5 46553c25 debug

 
mysqld: /data/src/10.5/storage/maria/ma_blockrec.c:5468: _ma_scan_block_record: Assertion `!(end_of_data > info->scan.dir_end)' failed.
 
190809 16:05:42 [ERROR] mysqld got signal 6 ;
 
 
 
#7  0x00007ff2fce66f12 in __GI___assert_fail (assertion=0x561b212d3278 "!(end_of_data > info->scan.dir_end)", file=0x561b212d1c80 "/data/src/10.5/storage/maria/ma_blockrec.c", line=5468, function=0x561b212d3c30 <__PRETTY_FUNCTION__.16869> "_ma_scan_block_record") at assert.c:101
 
#8  0x0000561b20d65636 in _ma_scan_block_record (info=0x7ff2d028f7e0, record=0x7ff2d01395b0 "\377", record_pos=0, skip_deleted=1 '\001') at /data/src/10.5/storage/maria/ma_blockrec.c:5468
 
#9  0x0000561b20d5210d in maria_scan (info=0x7ff2d028f7e0, record=0x7ff2d01395b0 "\377") at /data/src/10.5/storage/maria/ma_scan.c:54
 
#10 0x0000561b20cf85ef in ha_maria::rnd_next (this=0x7ff2d0197958, buf=0x7ff2d01395b0 "\377") at /data/src/10.5/storage/maria/ha_maria.cc:2459
 
#11 0x0000561b2062b4a7 in handler::ha_rnd_next (this=0x7ff2d0197958, buf=0x7ff2d01395b0 "\377") at /data/src/10.5/sql/handler.cc:2794
 
#12 0x0000561b207bc4a6 in rr_sequential (info=0x7ff2f0064ce0) at /data/src/10.5/sql/records.cc:477
 
#13 0x0000561b2025ec6d in READ_RECORD::read_record (this=0x7ff2f0064ce0) at /data/src/10.5/sql/records.h:69
 
#14 0x0000561b20400c92 in copy_data_between_tables (thd=0x7ff2d0000b10, from=0x7ff2d00baa00, to=0x7ff2d0293ff0, create=..., ignore=false, order_num=0, order=0x0, copied=0x7ff2f0065708, deleted=0x7ff2f0065710, keys_onoff=Alter_info::LEAVE_AS_IS, alter_ctx=0x7ff2f0067140) at /data/src/10.5/sql/sql_table.cc:10690
 
#15 0x0000561b203fedc2 in mysql_alter_table (thd=0x7ff2d0000b10, new_db=0x7ff2d00052b8, new_name=0x7ff2d00056c0, create_info=0x7ff2f0067d20, table_list=0x7ff2d0013470, alter_info=0x7ff2f0067c60, order_num=0, order=0x0, ignore=false) at /data/src/10.5/sql/sql_table.cc:10144
 
#16 0x0000561b2049754b in Sql_cmd_alter_table::execute (this=0x7ff2d0013b28, thd=0x7ff2d0000b10) at /data/src/10.5/sql/sql_alter.cc:522
 
#17 0x0000561b20311504 in mysql_execute_command (thd=0x7ff2d0000b10) at /data/src/10.5/sql/sql_parse.cc:6059
 
#18 0x0000561b2031679e in mysql_parse (thd=0x7ff2d0000b10, rawbuf=0x7ff2d0013388 "ALTER TABLE t1 ENGINE=Aria", length=26, parser_state=0x7ff2f0069180, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:7868
 
#19 0x0000561b20302b2b in dispatch_command (command=COM_QUERY, thd=0x7ff2d0000b10, packet=0x7ff2d0008321 "ALTER TABLE t1 ENGINE=Aria", packet_length=26, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1827
 
#20 0x0000561b203012e9 in do_command (thd=0x7ff2d0000b10) at /data/src/10.5/sql/sql_parse.cc:1360
 
#21 0x0000561b2048d8eb in do_handle_one_connection (connect=0x561b236f4050, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1413
 
#22 0x0000561b2048d62f in handle_one_connection (arg=0x561b236f4050) at /data/src/10.5/sql/sql_connect.cc:1309
 
#23 0x0000561b208b7c5f in pfs_spawn_thread (arg=0x561b2365e450) at /data/src/10.5/storage/perfschema/pfs.cc:1862
 
#24 0x00007ff2ff0164a4 in start_thread (arg=0x7ff2f006a700) at pthread_create.c:456
 
#25 0x00007ff2fcf23d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Not reproducible without encryption.

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

The problem is that S3 doesn't support encrypted tables, but there was no check for this.
The table was copied encrypted to S3 and the code who tried to scan the table could not
handle that.

Fixed by not creating an encrypted table when altering a table to S3.

Comment by Julien Fritsch [ 2023-12-05 ]

Automated message:
----------------------------
Since this issue has not been updated since 6 weeks, it's time to move it back to Stalled.

Comment by JiraAutomate [ 2023-12-05 ]

Automated message:
----------------------------
Since this issue has not been updated since 6 weeks, it's time to move it back to Stalled.

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