[MDEV-17844] Assertion `ulint(rec) == offsets[2]' failed in rec_offs_validate - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Affects Version/s: 10.5.0, 10.4(EOL)
Fix Version/s: 10.5.1, 10.4.13
Component/s: Storage Engine - InnoDB
Labels:
None

Description

https://travis-ci.org/elenst/travis-tests/jobs/459805353

10.4 7dcbc33db5bd5282f35266ead5d78095848ee0f5
mysqld: /home/travis/src/storage/innobase/rem/rem0rec.cc:525: bool rec_offs_validate(const rec_t, const dict_index_t, const ulint*): Assertion `ulint(rec) == offsets[2]' failed.
181126 20:04:56 [ERROR] mysqld got signal 6 ;

#7 0x00007f0d4b8b5c82 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8 0x00005577d03d4c63 in rec_offs_validate (rec=0x7f0d2f1f5898 "\200", index=0x0, offsets=0x5577d46c5d48) at /home/travis/src/storage/innobase/rem/rem0rec.cc:525
#9 0x00005577d03bb982 in page_zip_write_trx_id_and_roll_ptr (page_zip=0x7f0d2d7e84f8, rec=0x7f0d2f1f5898 "\200", offsets=0x5577d46c5d48, trx_id_col=2, trx_id=0, roll_ptr=36028797018963968, mtr=0x7f0d481f8e00) at /home/travis/src/storage/innobase/page/page0zip.cc:4124
#10 0x00005577d066a02e in row_undo_mod_clust (node=0x5577d5259b38, thr=0x5577d48965d8) at /home/travis/src/storage/innobase/row/row0umod.cc:488
#11 0x00005577d066c664 in row_undo_mod (node=0x5577d5259b38, thr=0x5577d48965d8) at /home/travis/src/storage/innobase/row/row0umod.cc:1383
#12 0x00005577d046a556 in row_undo (node=0x5577d5259b38, thr=0x5577d48965d8) at /home/travis/src/storage/innobase/row/row0undo.cc:441
#13 0x00005577d046a789 in row_undo_step (thr=0x5577d48965d8) at /home/travis/src/storage/innobase/row/row0undo.cc:497
#14 0x00005577d03ca5da in que_thr_step (thr=0x5577d48965d8) at /home/travis/src/storage/innobase/que/que0que.cc:1040
#15 0x00005577d03ca829 in que_run_threads_low (thr=0x5577d48965d8) at /home/travis/src/storage/innobase/que/que0que.cc:1104
#16 0x00005577d03caa1a in que_run_threads (thr=0x5577d48965d8) at /home/travis/src/storage/innobase/que/que0que.cc:1144
#17 0x00005577d04c821d in trx_rollback_to_savepoint_low (trx=0x7f0d48542518, savept=0x0) at /home/travis/src/storage/innobase/trx/trx0roll.cc:137
#18 0x00005577d04c869a in trx_rollback_for_mysql_low (trx=0x7f0d48542518) at /home/travis/src/storage/innobase/trx/trx0roll.cc:206
#19 0x00005577d04c89e7 in trx_rollback_for_mysql (trx=0x7f0d48542518) at /home/travis/src/storage/innobase/trx/trx0roll.cc:232
#20 0x00005577d02b7776 in innobase_rollback (hton=0x5577d38e81e0, thd=0x5577d44b3890, rollback_trx=false) at /home/travis/src/storage/innobase/handler/ha_innodb.cc:4718
#21 0x00005577d00a30bb in ha_rollback_trans (thd=0x5577d44b3890, all=false) at /home/travis/src/sql/handler.cc:1722
#22 0x00005577cff0e6c7 in trans_rollback_stmt (thd=0x5577d44b3890) at /home/travis/src/sql/transaction.cc:583
#23 0x00005577cfd9d7cb in mysql_execute_command (thd=0x5577d44b3890) at /home/travis/src/sql/sql_parse.cc:6341
#24 0x00005577cfda24a8 in mysql_parse (thd=0x5577d44b3890, rawbuf=0x5577d44c91f8 "LOAD DATA INFILE 'load_table100_innodb_compressed_int_autoinc' REPLACE INTO TABLE table100_innodb_compressed_int_autoinc /* QNO 11365 CON_ID 16 */", length=146, parser_state=0x7f0d481fa650, is_com_multi=false, is_next_command=false) at /home/travis/src/sql/sql_parse.cc:8092
#25 0x00005577cfd8f466 in dispatch_command (command=COM_QUERY, thd=0x5577d44b3890, packet=0x5577d44bce51 " LOAD DATA INFILE 'load_table100_innodb_compressed_int_autoinc' REPLACE INTO TABLE table100_innodb_compressed_int_autoinc /* QNO 11365 CON_ID 16 */ ", packet_length=148, is_com_multi=false, is_next_command=false) at /home/travis/src/sql/sql_parse.cc:1851
#26 0x00005577cfd8de83 in do_command (thd=0x5577d44b3890) at /home/travis/src/sql/sql_parse.cc:1396
#27 0x00005577cfef9208 in do_handle_one_connection (connect=0x5577d3829120) at /home/travis/src/sql/sql_connect.cc:1402
#28 0x00005577cfef8f59 in handle_one_connection (arg=0x5577d3829120) at /home/travis/src/sql/sql_connect.cc:1308
#29 0x00007f0d4c4fa6ba in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#30 0x00007f0d4b98f41d in clone () from /lib/x86_64-linux-gnu/libc.so.6

elenst-dev 33ad7f04959f76e6a6553f34ba131dd19884c4f4

perl ./runall-new.pl --basedir=/home/travis/server --vardir=/home/travis/logs/vardir --duration=350 --threads=6 --seed=1543262193 --reporters=Backtrace,ErrorLog,Deadlock --redefine=conf/mariadb/alter_table.yy --redefine=conf/mariadb/instant_add.yy --redefine=conf/mariadb/bulk_insert.yy --redefine=conf/mariadb/versioning.yy --redefine=conf/mariadb/sequences.yy --redefine=conf/mariadb/redefine_temporary_tables.yy --mysqld=--log_output=FILE --mysqld=--max-statement-time=30 --mysqld=--lock-wait-timeout=5 --mysqld=--loose-innodb-lock-wait-timeout=3 --mysqld=--loose-debug_assert_on_not_freed_memory=0 --grammar=conf/percona_qa/percona_qa.yy --gendata=conf/percona_qa/percona_qa.zz --mysqld=--loose-file-key-management-filename=/home/travis/rqg/conf/mariadb/encryption_keys.txt --engine=InnoDB --mysqld=--sql-mode=

Not reproducible right away.

Attachments

- Sort By Name
- Sort By Date
- Ascending
- Descending
- Thumbnails
- List
- Download All

MDEV-17844.yy
2019-06-28 16:09
0.9 kB
Matthias Leich

Issue Links

is caused by

MDEV-15562 Instant DROP COLUMN or changing the order of columns

Closed

Activity

Ascending order - Click to sort in descending order

Elena Stepanova added a comment - 2019-02-15 22:57

New occurrence: https://travis-ci.org/elenst/travis-tests/jobs/493761716 [2753 27 2]

Elena Stepanova added a comment - 2019-02-15 22:57 New occurrence: https://travis-ci.org/elenst/travis-tests/jobs/493761716 [2753 27 2]

Elena Stepanova added a comment - 2019-05-16 13:58

Still happens: https://travis-ci.org/elenst/travis-tests/jobs/531425640 3389 27 2

elenst-dev 7300634 Toolbox: 5d8e1cd

perl ./runall-new.pl --basedir=/home/travis/server --vardir=/home/travis/logs/vardir --duration=350 --threads=6 --seed=1557788185 --short-column-names --reporters=Backtrace,ErrorLog,Deadlock --validators=TransformerNoComparator --transformers=ExecuteAsExecuteImmediate,ExecuteAsInsertSelect,ExecuteAsUpdateDelete --redefine=conf/mariadb/alter_table.yy --redefine=conf/mariadb/instant_add.yy --redefine=conf/mariadb/modules/alter_table_columns.yy --redefine=conf/mariadb/modules/alter_table_indexes.yy --redefine=conf/mariadb/bulk_insert.yy --redefine=conf/mariadb/modules/admin.yy --redefine=conf/mariadb/modules/foreign_keys.yy -redefine=conf/mariadb/modules/locks.yy --redefine=conf/mariadb/modules/sql_mode.yy --redefine=conf/mariadb/redefine_temporary_tables.yy --redefine=conf/mariadb/versioning.yy --redefine=conf/mariadb/sequences.yy --mysqld=--log_output=FILE --mysqld=--max-statement-time=15 --mysqld=--lock-wait-timeout=10 --mysqld=--loose-innodb-lock-wait-timeout=5 --mysqld=--loose-debug_assert_on_not_freed_memory=0 --mysqld=--innodb-buffer-pool-size=2G --grammar=conf/partitioning/partitions.yy --gendata=conf/mariadb/innodb.zz --filter=/home/travis/mariadb-toolbox/travis/10.4-combo-filter-asan.ff --mysqld=--innodb-page-size=8K

Elena Stepanova added a comment - 2019-05-16 13:58 Still happens: https://travis-ci.org/elenst/travis-tests/jobs/531425640 3389 27 2 elenst-dev 7300634 Toolbox: 5d8e1cd perl ./runall-new.pl --basedir=/home/travis/server --vardir=/home/travis/logs/vardir --duration=350 --threads=6 --seed=1557788185 --short-column-names --reporters=Backtrace,ErrorLog,Deadlock --validators=TransformerNoComparator --transformers=ExecuteAsExecuteImmediate,ExecuteAsInsertSelect,ExecuteAsUpdateDelete --redefine=conf/mariadb/alter_table.yy --redefine=conf/mariadb/instant_add.yy --redefine=conf/mariadb/modules/alter_table_columns.yy --redefine=conf/mariadb/modules/alter_table_indexes.yy --redefine=conf/mariadb/bulk_insert.yy --redefine=conf/mariadb/modules/admin.yy --redefine=conf/mariadb/modules/foreign_keys.yy -redefine=conf/mariadb/modules/locks.yy --redefine=conf/mariadb/modules/sql_mode.yy --redefine=conf/mariadb/redefine_temporary_tables.yy --redefine=conf/mariadb/versioning.yy --redefine=conf/mariadb/sequences.yy --mysqld=--log_output=FILE --mysqld=--max-statement-time=15 --mysqld=--lock-wait-timeout=10 --mysqld=--loose-innodb-lock-wait-timeout=5 --mysqld=--loose-debug_assert_on_not_freed_memory=0 --mysqld=--innodb-buffer-pool-size=2G --grammar=conf/partitioning/partitions.yy --gendata=conf/mariadb/innodb.zz --filter=/home/travis/mariadb-toolbox/travis/10.4-combo-filter-asan.ff --mysqld=--innodb-page-size=8K

Matthias Leich added a comment - 2019-06-28 16:20 - edited

The uploaded MDEV-17844.yy is the simplified RQG grammar.

RQG setup:

perl rqg.pl \

--duration=300 \

--queries=1000000 \

--threads=12 \

--no_mask \

--seed=random \

--gendata_sql=conf/mariadb/table_stress.sql \

--rpl_mode=none \

--gendata=conf/mariadb/table_stress.zz \

--engine=InnoDB \

--mysqld=--lock-wait-timeout=86400 \

--mysqld=--innodb-lock-wait-timeout=50 \

--mysqld=--loose-idle_readonly_transaction_timeout=0 \

--mysqld=--sql_mode=traditional \

--mysqld=--net_write_timeout=60 \

--mysqld=--loose_innodb_use_native_aio=0 \

--mysqld=--slave-skip-errors=1049,1305,1539,1505 \

--mysqld=--loose-idle_write_transaction_timeout=0 \

--mysqld=--innodb_adaptive_hash_index=off \

--mysqld=--net_read_timeout=30 \

--mysqld=--interactive_timeout=28800 \

--mysqld=--connect_timeout=60 \

--mysqld=--slave_net_timeout=60 \

--mysqld=--loose-idle_transaction_timeout=0 \

--mysqld=--loose-table_lock_wait_timeout=50 \

--mysqld=--wait_timeout=28800 \

--mysqld=--loose_innodb_lock_schedule_algorithm=fcfs \

--mysqld=--log-output=file \

--whitelist_statuses='STATUS_SERVER_CRASHED' \

--whitelist_patterns='mysqld:.{1,100}rem0rec.cc:.{1,30}bool rec_offs_validate.{1,500} failed' \

--blacklist_statuses='STATUS_OK' \

--blacklist_patterns='Possible endless loop in grammar.','\[ERROR\] InnoDB: preallocating .{1,120} with error 28','  is truncated: expected core file size ' \

--reporters=ErrorLog,None,Backtrace \

--validators=None \

--grammar=MDEV-17844.yy \

.... certain settings specific to the testing environment.

It looks like InnoDB ROW_FORMAT = Compressed is the trouble maker.

I will try to write some MTR base replay test.

Matthias Leich added a comment - 2019-06-28 16:20 - edited The uploaded MDEV-17844.yy is the simplified RQG grammar. RQG setup: perl rqg.pl \ --duration=300 \ --queries=1000000 \ --threads=12 \ --no_mask \ --seed=random \ --gendata_sql=conf/mariadb/table_stress.sql \ --rpl_mode=none \ --gendata=conf/mariadb/table_stress.zz \ --engine=InnoDB \ --mysqld=--lock-wait-timeout=86400 \ --mysqld=--innodb-lock-wait-timeout=50 \ --mysqld=--loose-idle_readonly_transaction_timeout=0 \ --mysqld=--sql_mode=traditional \ --mysqld=--net_write_timeout=60 \ --mysqld=--loose_innodb_use_native_aio=0 \ --mysqld=--slave-skip-errors=1049,1305,1539,1505 \ --mysqld=--loose-idle_write_transaction_timeout=0 \ --mysqld=--innodb_adaptive_hash_index=off \ --mysqld=--net_read_timeout=30 \ --mysqld=--interactive_timeout=28800 \ --mysqld=--connect_timeout=60 \ --mysqld=--slave_net_timeout=60 \ --mysqld=--loose-idle_transaction_timeout=0 \ --mysqld=--loose-table_lock_wait_timeout=50 \ --mysqld=--wait_timeout=28800 \ --mysqld=--loose_innodb_lock_schedule_algorithm=fcfs \ --mysqld=--log-output=file \ --whitelist_statuses='STATUS_SERVER_CRASHED' \ --whitelist_patterns='mysqld:.{1,100}rem0rec.cc:.{1,30}bool rec_offs_validate.{1,500} failed' \ --blacklist_statuses='STATUS_OK' \ --blacklist_patterns='Possible endless loop in grammar.','\[ERROR\] InnoDB: preallocating .{1,120} with error 28',' is truncated: expected core file size ' \ --reporters=ErrorLog,None,Backtrace \ --validators=None \ --grammar=MDEV-17844.yy \ .... certain settings specific to the testing environment. It looks like InnoDB ROW_FORMAT = Compressed is the trouble maker. I will try to write some MTR base replay test.

Matthias Leich added a comment - 2019-11-05 12:06

This assert occurs in 10.5.0 too.

Matthias Leich added a comment - 2019-11-05 12:06 This assert occurs in 10.5.0 too.

Marko Mäkelä added a comment - 2020-01-31 08:04

This was only a debug check failure, not affecting release builds. It was introduced in ~~MDEV-15562~~.

Marko Mäkelä added a comment - 2020-01-31 08:04 This was only a debug check failure, not affecting release builds. It was introduced in MDEV-15562 .

Marko Mäkelä added a comment - 2020-01-31 08:05 - edited

Note: due to ~~MDEV-20950~~ the assertion expression had later been changed to
!memcmp(&rec, &offsets[RECORD_OFFSET], sizeof(rec)).

Marko Mäkelä added a comment - 2020-01-31 08:05 - edited Note: due to MDEV-20950 the assertion expression had later been changed to !memcmp(&rec, &offsets[RECORD_OFFSET], sizeof(rec)) .

Elena Stepanova added a comment - 2020-02-23 13:22 - edited

Too late, I've got a test case which seems to reproduce the failure reliably (the variation !memcmp(&rec, &offsets[RECORD_OFFSET], sizeof(rec))), at least it happens for me every time I run the test.
It stops failing after the commit which fixes this bug. marko, please feel free to decide if you want to add it to the regression suite. The fix came without a test case, but on the other hand, the commit comment says that the assertion was bogus, so maybe no test case is needed.

--source include/have_innodb.inc

--source include/have_sequence.inc

CREATE TABLE t1 (a INT) ENGINE=InnoDB ROW_FORMAT=COMPRESSED;

INSERT INTO t1 SELECT NULL FROM seq_1_to_16384;

SET max_statement_time= 1;

--error ER_STATEMENT_TIMEOUT

UPDATE t1 SET a = 0;

# Cleanup

DROP TABLE t1;

10.4 88bcc7f2
mysqld: /data/src/10.4-bug/storage/innobase/rem/rem0rec.cc:510: bool rec_offs_validate(const rec_t, const dict_index_t, const offset_t*): Assertion `!memcmp(&rec, &offsets[RECORD_OFFSET], sizeof(rec))' failed.
200223 15:21:29 [ERROR] mysqld got signal 6 ;

#6 0x00007f7cb9f30e67 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x56494f6d3a00 "!memcmp(&rec, &offsets[RECORD_OFFSET], sizeof(rec))", file=file@entry=0x56494f6d3700 "/data/src/10.4-bug/storage/innobase/rem/rem0rec.cc", line=line@entry=510, function=function@entry=0x56494f6d58a0 <rec_offs_validate(unsigned char const, dict_index_t const, unsigned short const)::__PRETTY_FUNCTION__> "bool rec_offs_validate(const rec_t, const dict_index_t, const offset_t)") at assert.c:92
#7 0x00007f7cb9f30f12 in __GI___assert_fail (assertion=0x56494f6d3a00 "!memcmp(&rec, &offsets[RECORD_OFFSET], sizeof(rec))", file=0x56494f6d3700 "/data/src/10.4-bug/storage/innobase/rem/rem0rec.cc", line=510, function=0x56494f6d58a0 <rec_offs_validate(unsigned char const, dict_index_t const, unsigned short const)::__PRETTY_FUNCTION__> "bool rec_offs_validate(const rec_t, const dict_index_t, const offset_t)") at assert.c:101
#8 0x000056494ee533c3 in rec_offs_validate (rec=0x7f7caf94810f "", index=0x0, offsets=0x7f7c60072cb0) at /data/src/10.4-bug/storage/innobase/rem/rem0rec.cc:510
#9 0x000056494ee355bf in page_zip_write_trx_id_and_roll_ptr (page_zip=0x7f7caf42e5c0, rec=0x7f7caf94810f "", offsets=0x7f7c60072cb0, trx_id_col=1, trx_id=0, roll_ptr=36028797018963968, mtr=0x7f7cb40d8340) at /data/src/10.4-bug/storage/innobase/page/page0zip.cc:4133
#10 0x000056494f14c096 in row_undo_mod_clust (node=0x7f7c60071f68, thr=0x7f7c60071d98) at /data/src/10.4-bug/storage/innobase/row/row0umod.cc:488
#11 0x000056494f14ec05 in row_undo_mod (node=0x7f7c60071f68, thr=0x7f7c60071d98) at /data/src/10.4-bug/storage/innobase/row/row0umod.cc:1383
#12 0x000056494ef04632 in row_undo (node=0x7f7c60071f68, thr=0x7f7c60071d98) at /data/src/10.4-bug/storage/innobase/row/row0undo.cc:442
#13 0x000056494ef048ef in row_undo_step (thr=0x7f7c60071d98) at /data/src/10.4-bug/storage/innobase/row/row0undo.cc:499
#14 0x000056494ee458d2 in que_thr_step (thr=0x7f7c60071d98) at /data/src/10.4-bug/storage/innobase/que/que0que.cc:1035
#15 0x000056494ee45b85 in que_run_threads_low (thr=0x7f7c60071d98) at /data/src/10.4-bug/storage/innobase/que/que0que.cc:1099
#16 0x000056494ee45dd5 in que_run_threads (thr=0x7f7c60071d98) at /data/src/10.4-bug/storage/innobase/que/que0que.cc:1139
#17 0x000056494ef6e3a0 in trx_rollback_to_savepoint_low (trx=0x7f7cafc00140, savept=0x0) at /data/src/10.4-bug/storage/innobase/trx/trx0roll.cc:136
#18 0x000056494ef6e82b in trx_rollback_for_mysql_low (trx=0x7f7cafc00140) at /data/src/10.4-bug/storage/innobase/trx/trx0roll.cc:210
#19 0x000056494ef6ecec in trx_rollback_for_mysql (trx=0x7f7cafc00140) at /data/src/10.4-bug/storage/innobase/trx/trx0roll.cc:236
#20 0x000056494ed01857 in innobase_rollback (hton=0x5649526d0ab0, thd=0x7f7c60000af0, rollback_trx=false) at /data/src/10.4-bug/storage/innobase/handler/ha_innodb.cc:4721
#21 0x000056494eabe082 in ha_rollback_trans (thd=0x7f7c60000af0, all=false) at /data/src/10.4-bug/sql/handler.cc:1885
#22 0x000056494e8f6afd in trans_rollback_stmt (thd=0x7f7c60000af0) at /data/src/10.4-bug/sql/transaction.cc:495
#23 0x000056494e76574b in mysql_execute_command (thd=0x7f7c60000af0) at /data/src/10.4-bug/sql/sql_parse.cc:6152
#24 0x000056494e76a853 in mysql_parse (thd=0x7f7c60000af0, rawbuf=0x7f7c60013198 "UPDATE t1 SET a = 0", length=19, parser_state=0x7f7cb40da160, is_com_multi=false, is_next_command=false) at /data/src/10.4-bug/sql/sql_parse.cc:7901
#25 0x000056494e755a20 in dispatch_command (command=COM_QUERY, thd=0x7f7c60000af0, packet=0x7f7c601372f1 "UPDATE t1 SET a = 0", packet_length=19, is_com_multi=false, is_next_command=false) at /data/src/10.4-bug/sql/sql_parse.cc:1842
#26 0x000056494e7540ad in do_command (thd=0x7f7c60000af0) at /data/src/10.4-bug/sql/sql_parse.cc:1360
#27 0x000056494e8dd2c7 in do_handle_one_connection (connect=0x564952af2e20) at /data/src/10.4-bug/sql/sql_connect.cc:1412
#28 0x000056494e8dd016 in handle_one_connection (arg=0x564952af2e20) at /data/src/10.4-bug/sql/sql_connect.cc:1316
#29 0x000056494f2e5713 in pfs_spawn_thread (arg=0x564952a16ba0) at /data/src/10.4-bug/storage/perfschema/pfs.cc:1869
#30 0x00007f7cbbeb94a4 in start_thread (arg=0x7f7cb40db700) at pthread_create.c:456
#31 0x00007f7cb9fedd0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Elena Stepanova added a comment - 2020-02-23 13:22 - edited Too late, I've got a test case which seems to reproduce the failure reliably (the variation !memcmp(&rec, &offsets [RECORD_OFFSET] , sizeof(rec)) ), at least it happens for me every time I run the test. It stops failing after the commit which fixes this bug. marko , please feel free to decide if you want to add it to the regression suite. The fix came without a test case, but on the other hand, the commit comment says that the assertion was bogus, so maybe no test case is needed. --source include/have_innodb.inc --source include/have_sequence.inc CREATE TABLE t1 (a INT ) ENGINE=InnoDB ROW_FORMAT=COMPRESSED; INSERT INTO t1 SELECT NULL FROM seq_1_to_16384; SET max_statement_time= 1; --error ER_STATEMENT_TIMEOUT UPDATE t1 SET a = 0; # Cleanup DROP TABLE t1; 10.4 88bcc7f2 mysqld: /data/src/10.4-bug/storage/innobase/rem/rem0rec.cc:510: bool rec_offs_validate(const rec_t*, const dict_index_t*, const offset_t*): Assertion `!memcmp(&rec, &offsets[RECORD_OFFSET], sizeof(rec))' failed. 200223 15:21:29 [ERROR] mysqld got signal 6 ; #6 0x00007f7cb9f30e67 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x56494f6d3a00 "!memcmp(&rec, &offsets[RECORD_OFFSET], sizeof(rec))", file=file@entry=0x56494f6d3700 "/data/src/10.4-bug/storage/innobase/rem/rem0rec.cc", line=line@entry=510, function=function@entry=0x56494f6d58a0 <rec_offs_validate(unsigned char const*, dict_index_t const*, unsigned short const*)::__PRETTY_FUNCTION__> "bool rec_offs_validate(const rec_t*, const dict_index_t*, const offset_t*)") at assert.c:92 #7 0x00007f7cb9f30f12 in __GI___assert_fail (assertion=0x56494f6d3a00 "!memcmp(&rec, &offsets[RECORD_OFFSET], sizeof(rec))", file=0x56494f6d3700 "/data/src/10.4-bug/storage/innobase/rem/rem0rec.cc", line=510, function=0x56494f6d58a0 <rec_offs_validate(unsigned char const*, dict_index_t const*, unsigned short const*)::__PRETTY_FUNCTION__> "bool rec_offs_validate(const rec_t*, const dict_index_t*, const offset_t*)") at assert.c:101 #8 0x000056494ee533c3 in rec_offs_validate (rec=0x7f7caf94810f "", index=0x0, offsets=0x7f7c60072cb0) at /data/src/10.4-bug/storage/innobase/rem/rem0rec.cc:510 #9 0x000056494ee355bf in page_zip_write_trx_id_and_roll_ptr (page_zip=0x7f7caf42e5c0, rec=0x7f7caf94810f "", offsets=0x7f7c60072cb0, trx_id_col=1, trx_id=0, roll_ptr=36028797018963968, mtr=0x7f7cb40d8340) at /data/src/10.4-bug/storage/innobase/page/page0zip.cc:4133 #10 0x000056494f14c096 in row_undo_mod_clust (node=0x7f7c60071f68, thr=0x7f7c60071d98) at /data/src/10.4-bug/storage/innobase/row/row0umod.cc:488 #11 0x000056494f14ec05 in row_undo_mod (node=0x7f7c60071f68, thr=0x7f7c60071d98) at /data/src/10.4-bug/storage/innobase/row/row0umod.cc:1383 #12 0x000056494ef04632 in row_undo (node=0x7f7c60071f68, thr=0x7f7c60071d98) at /data/src/10.4-bug/storage/innobase/row/row0undo.cc:442 #13 0x000056494ef048ef in row_undo_step (thr=0x7f7c60071d98) at /data/src/10.4-bug/storage/innobase/row/row0undo.cc:499 #14 0x000056494ee458d2 in que_thr_step (thr=0x7f7c60071d98) at /data/src/10.4-bug/storage/innobase/que/que0que.cc:1035 #15 0x000056494ee45b85 in que_run_threads_low (thr=0x7f7c60071d98) at /data/src/10.4-bug/storage/innobase/que/que0que.cc:1099 #16 0x000056494ee45dd5 in que_run_threads (thr=0x7f7c60071d98) at /data/src/10.4-bug/storage/innobase/que/que0que.cc:1139 #17 0x000056494ef6e3a0 in trx_rollback_to_savepoint_low (trx=0x7f7cafc00140, savept=0x0) at /data/src/10.4-bug/storage/innobase/trx/trx0roll.cc:136 #18 0x000056494ef6e82b in trx_rollback_for_mysql_low (trx=0x7f7cafc00140) at /data/src/10.4-bug/storage/innobase/trx/trx0roll.cc:210 #19 0x000056494ef6ecec in trx_rollback_for_mysql (trx=0x7f7cafc00140) at /data/src/10.4-bug/storage/innobase/trx/trx0roll.cc:236 #20 0x000056494ed01857 in innobase_rollback (hton=0x5649526d0ab0, thd=0x7f7c60000af0, rollback_trx=false) at /data/src/10.4-bug/storage/innobase/handler/ha_innodb.cc:4721 #21 0x000056494eabe082 in ha_rollback_trans (thd=0x7f7c60000af0, all=false) at /data/src/10.4-bug/sql/handler.cc:1885 #22 0x000056494e8f6afd in trans_rollback_stmt (thd=0x7f7c60000af0) at /data/src/10.4-bug/sql/transaction.cc:495 #23 0x000056494e76574b in mysql_execute_command (thd=0x7f7c60000af0) at /data/src/10.4-bug/sql/sql_parse.cc:6152 #24 0x000056494e76a853 in mysql_parse (thd=0x7f7c60000af0, rawbuf=0x7f7c60013198 "UPDATE t1 SET a = 0", length=19, parser_state=0x7f7cb40da160, is_com_multi=false, is_next_command=false) at /data/src/10.4-bug/sql/sql_parse.cc:7901 #25 0x000056494e755a20 in dispatch_command (command=COM_QUERY, thd=0x7f7c60000af0, packet=0x7f7c601372f1 "UPDATE t1 SET a = 0", packet_length=19, is_com_multi=false, is_next_command=false) at /data/src/10.4-bug/sql/sql_parse.cc:1842 #26 0x000056494e7540ad in do_command (thd=0x7f7c60000af0) at /data/src/10.4-bug/sql/sql_parse.cc:1360 #27 0x000056494e8dd2c7 in do_handle_one_connection (connect=0x564952af2e20) at /data/src/10.4-bug/sql/sql_connect.cc:1412 #28 0x000056494e8dd016 in handle_one_connection (arg=0x564952af2e20) at /data/src/10.4-bug/sql/sql_connect.cc:1316 #29 0x000056494f2e5713 in pfs_spawn_thread (arg=0x564952a16ba0) at /data/src/10.4-bug/storage/perfschema/pfs.cc:1869 #30 0x00007f7cbbeb94a4 in start_thread (arg=0x7f7cb40db700) at pthread_create.c:456 #31 0x00007f7cb9fedd0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Marko Mäkelä added a comment - 2020-02-24 09:08

Thanks, elenst. If we were to add a test to the regression suite (I am not sure we should), then I think that it should be made timing-independent. Would the following work?

--source include/have_innodb.inc

--source include/have_sequence.inc

CREATE TABLE t1 (a INT) ENGINE=InnoDB ROW_FORMAT=COMPRESSED;

INSERT INTO t1 SELECT NULL FROM seq_1_to_16384;

BEGIN;

UPDATE t1 SET a = 0;

ROLLBACK;

DROP TABLE t1;

If the above works, what would be the smallest number of rows to trigger the assertion failure?

Marko Mäkelä added a comment - 2020-02-24 09:08 Thanks, elenst . If we were to add a test to the regression suite (I am not sure we should), then I think that it should be made timing-independent. Would the following work? --source include/have_innodb.inc --source include/have_sequence.inc CREATE TABLE t1 (a INT ) ENGINE=InnoDB ROW_FORMAT=COMPRESSED; INSERT INTO t1 SELECT NULL FROM seq_1_to_16384; BEGIN ; UPDATE t1 SET a = 0; ROLLBACK ; DROP TABLE t1; If the above works, what would be the smallest number of rows to trigger the assertion failure?

People

Assignee:: Marko Mäkelä

Reporter:: Elena Stepanova

Votes:: 0 Vote for this issue

Watchers:: 3 Start watching this issue

Dates

Created:: 2018-11-27 00:16

Updated:: 2020-02-24 09:08

Resolved:: 2020-01-31 08:04

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server

Details

Description

Attachments

Attachments

Issue Links

Activity

People

Dates

Git Integration