[MDEV-14906] Assertion `index->is_instant()' failed in rec_init_offsets_comp_ordinary upon DELETE from table - Jira

XML

Word

Printable

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Affects Version/s: 10.3(EOL)
Fix Version/s: 10.3.7
Component/s: Storage Engine - InnoDB
Labels:
None

Description

Note: run the test case with --mem --repeat=N. For me N=10 has always been enough so far, but it can vary on different machines. --mem is important, at least on my machines, apparently the test is not concurrent enough when it's run on disk.

--source include/have_innodb.inc

--connect (con1,localhost,root,,test)

CREATE TABLE IF NOT EXISTS t1 (a INT, b INT) ENGINE = InnoDB;

INSERT INTO t1 VALUES (1,1),(1,1);

ALTER TABLE t1 DROP COLUMN a;

ALTER TABLE t1 ADD COLUMN extra INT;

ALTER TABLE t1 CHANGE COLUMN extra a INT;

ALTER TABLE t1 ADD UNIQUE KEY (a);

DELETE FROM t1;

--send

INSERT INTO t1 VALUES (3,3),(3,3);

--connection default

DELETE FROM t1;

# Cleanup

--connection con1

--error 0,ER_DUP_ENTRY

--reap

--disconnect con1

--connection default

DROP TABLE t1;

10.3 b2c47400349
mysqld: /data/src/10.3/storage/innobase/rem/rem0rec.cc:349: void rec_init_offsets_comp_ordinary(const rec_t, const dict_index_t, ulint*, rec_leaf_format): Assertion `index->is_instant()' failed.
180430 4:29:19 [ERROR] mysqld got signal 6 ;

#7 0x00007f207bf03ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8 0x000055e0d455ebb3 in rec_init_offsets_comp_ordinary (rec=0x7f201c07ece7 "", index=0x7f2020087c98, offsets=0x7f2075246460, format=REC_LEAF_COLUMNS_ADDED) at /data/src/10.3/storage/innobase/rem/rem0rec.cc:349
#9 0x000055e0d455fb6b in rec_init_offsets (rec=0x7f201c07ece7 "", index=0x7f2020087c98, leaf=true, offsets=0x7f2075246460) at /data/src/10.3/storage/innobase/rem/rem0rec.cc:617
#10 0x000055e0d4560751 in rec_get_offsets_func (rec=0x7f201c07ece7 "", index=0x7f2020087c98, offsets=0x7f2075246460, leaf=true, n_fields=1, file=0x55e0d4be8e98 "/data/src/10.3/storage/innobase/rem/rem0rec.cc", line=1754, heap=0x7f2075246400) at /data/src/10.3/storage/innobase/rem/rem0rec.cc:877
#11 0x000055e0d456332f in rec_copy_prefix_to_dtuple (tuple=0x7f201c07e168, rec=0x7f201c07ece7 "", index=0x7f2020087c98, is_leaf=true, n_fields=1, heap=0x7f201c07e0e0) at /data/src/10.3/storage/innobase/rem/rem0rec.cc:1754
#12 0x000055e0d474336b in dict_index_build_data_tuple (rec=0x7f201c07ece7 "", index=0x7f2020087c98, leaf=true, n_fields=1, heap=0x7f201c07e0e0) at /data/src/10.3/storage/innobase/dict/dict0dict.cc:5638
#13 0x000055e0d46c9363 in btr_pcur_restore_position_func (latch_mode=1, cursor=0x7f201c0cf650, file=0x55e0d4c190d8 "/data/src/10.3/storage/innobase/row/row0sel.cc", line=3529, mtr=0x7f2075247420) at /data/src/10.3/storage/innobase/btr/btr0pcur.cc:334
#14 0x000055e0d45e5af6 in sel_restore_position_for_mysql (same_user_rec=0x7f2075246aa0, latch_mode=1, pcur=0x7f201c0cf650, moves_up=1, mtr=0x7f2075247420) at /data/src/10.3/storage/innobase/row/row0sel.cc:3529
#15 0x000055e0d45eafd2 in row_search_mvcc (buf=0x7f201c06c588 "\377", mode=PAGE_CUR_G, prebuilt=0x7f201c0cf488, match_mode=0, direction=0) at /data/src/10.3/storage/innobase/row/row0sel.cc:5645
#16 0x000055e0d445a332 in ha_innobase::index_read (this=0x7f201c083f58, buf=0x7f201c06c588 "\377", key_ptr=0x0, key_len=0, find_flag=HA_READ_AFTER_KEY) at /data/src/10.3/storage/innobase/handler/ha_innodb.cc:9339
#17 0x000055e0d445b5fe in ha_innobase::index_first (this=0x7f201c083f58, buf=0x7f201c06c588 "\377") at /data/src/10.3/storage/innobase/handler/ha_innodb.cc:9757
#18 0x000055e0d445b809 in ha_innobase::rnd_next (this=0x7f201c083f58, buf=0x7f201c06c588 "\377") at /data/src/10.3/storage/innobase/handler/ha_innodb.cc:9850
#19 0x000055e0d413d1ac in handler::ha_rnd_next (this=0x7f201c083f58, buf=0x7f201c06c588 "\377") at /data/src/10.3/sql/handler.cc:2762
#20 0x000055e0d42bbf5a in rr_sequential (info=0x7f2075247d20) at /data/src/10.3/sql/records.cc:485
#21 0x000055e0d3dbfba9 in READ_RECORD::read_record (this=0x7f2075247d20) at /data/src/10.3/sql/records.h:73
#22 0x000055e0d42d99e3 in mysql_delete (thd=0x7f201c000b00, table_list=0x7f201c014f78, conds=0x0, order_list=0x7f201c005348, limit=18446744073709551615, options=0, result=0x0) at /data/src/10.3/sql/sql_delete.cc:726
#23 0x000055e0d3e59fbe in mysql_execute_command (thd=0x7f201c000b00) at /data/src/10.3/sql/sql_parse.cc:4922
#24 0x000055e0d3e63a46 in mysql_parse (thd=0x7f201c000b00, rawbuf=0x7f201c014eb0 "DELETE FROM t1", length=14, parser_state=0x7f20752495d0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:8001
#25 0x000055e0d3e51229 in dispatch_command (command=COM_QUERY, thd=0x7f201c000b00, packet=0x7f201c125fb1 "DELETE FROM t1", packet_length=14, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1846
#26 0x000055e0d3e4fc68 in do_command (thd=0x7f201c000b00) at /data/src/10.3/sql/sql_parse.cc:1391
#27 0x000055e0d3fb2aef in do_handle_one_connection (connect=0x55e0d7f0d2a0) at /data/src/10.3/sql/sql_connect.cc:1402
#28 0x000055e0d3fb287c in handle_one_connection (arg=0x55e0d7f0d2a0) at /data/src/10.3/sql/sql_connect.cc:1308
#29 0x000055e0d4436a8d in pfs_spawn_thread (arg=0x55e0d7f15720) at /data/src/10.3/storage/perfschema/pfs.cc:1862
#30 0x00007f207dbda494 in start_thread (arg=0x7f207524a700) at pthread_create.c:333
#31 0x00007f207bfc093f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Could not reproduce on 10.2

Results of previous preliminary analysis

This part contains some data from early stages, before we had any test case at all, which was collected initially or upon Marko's request, as well as Marko's notes on it. Feel free to remove it if it's no longer needed.

10.3 0b597d3ab2494bc1d
mysqld: /home/elenst/git/10.3/storage/innobase/rem/rem0rec.cc:349: void rec_init_offsets_comp_ordinary(const rec_t, const dict_index_t, ulint*, rec_leaf_format): Assertion `index->is_instant()' failed.
mysqld: /home/elenst/git/10.3/storage/innobase/rem/rem0rec.cc:349: void rec_init_offsets_comp_ordinary(const rec_t, const dict_index_t, ulint*, rec_leaf_format): Assertion `index->is_instant()' failed.
180109 19:27:40 [ERROR] mysqld got signal 6 ;

#3 0x00007ff1aab20c82 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#4 0x000056026d7300c9 in rec_init_offsets_comp_ordinary (rec=0x7ff124086ef7 "", index=0x7ff11409eab8, offsets=0x7ff1a80b7b10, format=REC_LEAF_COLUMNS_ADDED) at /home/elenst/git/10.3/storage/innobase/rem/rem0rec.cc:349
#5 0x000056026d731097 in rec_init_offsets (rec=0x7ff124086ef7 "", index=0x7ff11409eab8, leaf=true, offsets=0x7ff1a80b7b10) at /home/elenst/git/10.3/storage/innobase/rem/rem0rec.cc:617
#6 0x000056026d731c86 in rec_get_offsets_func (rec=0x7ff124086ef7 "", index=0x7ff11409eab8, offsets=0x7ff1a80b7b10, leaf=true, n_fields=1, file=0x56026de880c0 "/home/elenst/git/10.3/storage/innobase/rem/rem0rec.cc",
line=1760, heap=0x7ff1a80b7ab0) at /home/elenst/git/10.3/storage/innobase/rem/rem0rec.cc:877
#7 0x000056026d734897 in rec_copy_prefix_to_dtuple (tuple=0x7ff128037908, rec=0x7ff124086ef7 "", index=0x7ff11409eab8, is_leaf=true, n_fields=1, heap=0x7ff128037880)
at /home/elenst/git/10.3/storage/innobase/rem/rem0rec.cc:1760
#8 0x000056026d92921b in dict_index_build_data_tuple (rec=0x7ff124086ef7 "", index=0x7ff11409eab8, leaf=true, n_fields=1, heap=0x7ff128037880) at /home/elenst/git/10.3/storage/innobase/dict/dict0dict.cc:5683
#9 0x000056026d8abb3c in btr_pcur_restore_position_func (latch_mode=1, cursor=0x7ff1140fde90, file=0x56026deb8178 "/home/elenst/git/10.3/storage/innobase/row/row0sel.cc", line=3596, mtr=0x7ff1a80b8d40)
at /home/elenst/git/10.3/storage/innobase/btr/btr0pcur.cc:335
#10 0x000056026d7bba52 in sel_restore_position_for_mysql (same_user_rec=0x7ff1a80b8170, latch_mode=1, pcur=0x7ff1140fde90, moves_up=1, mtr=0x7ff1a80b8d40) at /home/elenst/git/10.3/storage/innobase/row/row0sel.cc:3596
#11 0x000056026d7c0ee6 in row_search_mvcc (buf=0x7ff114101e48 "\377", mode=PAGE_CUR_G, prebuilt=0x7ff1140fdcc8, match_mode=0, direction=0) at /home/elenst/git/10.3/storage/innobase/row/row0sel.cc:5708
#12 0x000056026d6207e8 in ha_innobase::index_read (this=0x7ff1140c68a8, buf=0x7ff114101e48 "\377", key_ptr=0x0, key_len=0, find_flag=HA_READ_AFTER_KEY) at /home/elenst/git/10.3/storage/innobase/handler/ha_innodb.cc:9614
#13 0x000056026d621c34 in ha_innobase::index_first (this=0x7ff1140c68a8, buf=0x7ff114101e48 "\377") at /home/elenst/git/10.3/storage/innobase/handler/ha_innodb.cc:10052
#14 0x000056026d621eb4 in ha_innobase::rnd_next (this=0x7ff1140c68a8, buf=0x7ff114101e48 "\377") at /home/elenst/git/10.3/storage/innobase/handler/ha_innodb.cc:10148
#15 0x000056026d3f4390 in handler::ha_rnd_next (this=0x7ff1140c68a8, buf=0x7ff114101e48 "\377") at /home/elenst/git/10.3/sql/handler.cc:2723
#16 0x000056026d56d5d0 in rr_sequential (info=0x7ff1a80b9650) at /home/elenst/git/10.3/sql/records.cc:485
#17 0x000056026d092e99 in READ_RECORD::read_record (this=0x7ff1a80b9650) at /home/elenst/git/10.3/sql/records.h:73
#18 0x000056026d59f228 in mysql_delete (thd=0x7ff128000b00, table_list=0x7ff128013960, conds=0x7ff128014458, order_list=0x7ff1280051e0, limit=18446744073709551615, options=549755813888, result=0x0)
at /home/elenst/git/10.3/sql/sql_delete.cc:676
#19 0x000056026d1220ff in mysql_execute_command (thd=0x7ff128000b00) at /home/elenst/git/10.3/sql/sql_parse.cc:4893
#20 0x000056026d12bd28 in mysql_parse (thd=0x7ff128000b00, rawbuf=0x7ff128013828 "DELETE FROM t1 WHERE col2 = 2 OR col2 IS NULL /* QNO 7653 CON_ID 17 */", length=71, parser_state=0x7ff1a80ba660, is_com_multi=false,
is_next_command=false) at /home/elenst/git/10.3/sql/sql_parse.cc:7968
#21 0x000056026d1193cd in dispatch_command (command=COM_QUERY, thd=0x7ff128000b00, packet=0x7ff12800b061 "DELETE FROM t1 WHERE col2 = 2 OR col2 IS NULL /* QNO 7653 CON_ID 17 */ ", packet_length=72, is_com_multi=false,
is_next_command=false) at /home/elenst/git/10.3/sql/sql_parse.cc:1825
#22 0x000056026d117dfa in do_command (thd=0x7ff128000b00) at /home/elenst/git/10.3/sql/sql_parse.cc:1369
#23 0x000056026d2708bf in do_handle_one_connection (connect=0x560270c3b0a0) at /home/elenst/git/10.3/sql/sql_connect.cc:1401
#24 0x000056026d27063f in handle_one_connection (arg=0x560270c3b0a0) at /home/elenst/git/10.3/sql/sql_connect.cc:1307
#25 0x00007ff1ab7646ba in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#26 0x00007ff1aabf982d in clone () from /lib/x86_64-linux-gnu/libc.so.6

experimental 3279504130c1072

perl ./runall-new.pl --duration=3600 --threads=6 --reporters=Backtrace,ErrorLog,Deadlock --validators=TransformerNoComparator --transformers=ConvertSubqueriesToViews,ConvertTablesToDerived,Count,DisableOptimizations,Distinct,EnableOptimizations,ExecuteAsCTE,ExecuteAsDeleteReturning,ExecuteAsDerived,ExecuteAsExcept,ExecuteAsExecuteImmediate,ExecuteAsInsertSelect,ExecuteAsIntersect,ExecuteAsSelectItem,ExecuteAsUnion,ExecuteAsUpdateDelete,ExecuteAsView,ExecuteAsWhereSubquery,Having,InlineSubqueries,InlineVirtualColumns,LimitRowsExamined,OrderBy,StraightJoin,ExecuteAsPreparedTwice,ExecuteAsTrigger,ExecuteAsSPTwice,ExecuteAsFunctionTwice --redefine=conf/mariadb/general-workarounds.yy --mysqld=--log_output=FILE --mysqld=--log_bin_trust_function_creators=1 --mysqld=--log-bin --mysqld=--max-statement-time=30 --mysqld=--loose-debug_assert_on_not_freed_memory=0 --views --redefine=conf/mariadb/sequences.yy --basedir=/home/elenst/git/10.3 --grammar=conf/runtime/alter_online.yy --gendata=conf/runtime/alter_online.zz --engine=Aria --mysqld=--default-storage-engine=Aria --vardir=/home/elenst/test_results/mdev14643-2

Not easily reproducible.

Some data collected upon Marko's request:

(gdb) p/x rec[-6]@6

$1 = {0x0, 0x20, 0x0, 0x44, 0xfe, 0x90}

(gdb) p *index->fields@index->n_fields

$2 = {{col = 0x7ff11409e358, name = {m_name = 0x7ff11409e292 "DB_ROW_ID"}, prefix_len = 0, fixed_len = 6}, {col = 0x7ff11409e378, name = {m_name = 0x7ff11409e29c "DB_TRX_ID"}, prefix_len = 0, fixed_len = 6}, {

    col = 0x7ff11409e398, name = {m_name = 0x7ff11409e2a6 "DB_ROLL_PTR"}, prefix_len = 0, fixed_len = 7}, {col = 0x7ff11409e2b8, name = {m_name = 0x7ff11409e278 "col4"}, prefix_len = 0, fixed_len = 0}, {

    col = 0x7ff11409e2d8, name = {m_name = 0x7ff11409e27d "col2"}, prefix_len = 0, fixed_len = 4}, {col = 0x7ff11409e2f8, name = {m_name = 0x7ff11409e282 "col3"}, prefix_len = 0, fixed_len = 4}, {col = 0x7ff11409e318,

    name = {m_name = 0x7ff11409e287 "col1"}, prefix_len = 0, fixed_len = 4}, {col = 0x7ff11409e338, name = {m_name = 0x7ff11409e28c "extra"}, prefix_len = 0, fixed_len = 4}}

marko:

ok, delete-marked record, no PK. `p/x *rec@6+6+7+4+4+4+4`
I hope I got the correct amount (curiously, all fields look fixed-length)

(gdb) p/x *rec@6+6+7+4+4+4+4

$3 = {0x0, 0x0, 0x0, 0x0, 0x6, 0xac, 0x7f, 0x0, 0x0, 0x20, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x95, 0x7, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x20, 0xdc, 0x1, 0x24, 0xf1, 0x7f, 0x0, 0x0, 0xa0, 0x76}

marko:

marko [19:43]
strange: `rec[6]` is `0x7f`. it should be the MSB of `DB_TRX_ID` and rather small

(gdb) p/x trx_sys.max_trx_id

$4 = 0x4146

marko:

there is nothing close to 0x4146 (big-endian format) in the record. it looks totally corrupted to me
what about the other thread? or were there 2 threads asserting?
also, `dump binary memory /tmp/page.bin $page $page+srv_page_size` where `$page` is `rec&(srv_page_size-1)`
so that I can check the page dump. also, I'd like to know the `rec` in that case
adaptive hash index corruption? just guessing.

(gdb) thread 36

[Switching to thread 36 (Thread 0x7ff1a8105700 (LWP 10211))]

#0  0x00007ff1aabbe86a in fork () from /lib/x86_64-linux-gnu/libc.so.6

(gdb) f 10

#10 0x000056026d7300c9 in rec_init_offsets_comp_ordinary (rec=0x7ff1200c6077 "", index=0x7ff11409eab8, offsets=0x7ff1a8101eb0, format=REC_LEAF_COLUMNS_ADDED) at /home/elenst/git/10.3/storage/innobase/rem/rem0rec.cc:349

349            ut_ad(index->is_instant());

(gdb) p/x trx_sys.max_trx_id

$8 = 0x4146

marko:

it is total garbage. no "infimum" or "supremum", and large sections filled with 0x8f (TRASH). stray write into the InnoDB buffer pool from somewhere

use ASAN and ASAN_OPTIONS=abort_on_error=1,disable_coredump=0

no, it could be a legitimate page; there is something at the end of it

otoh, the page contents look like some SYS_ table page, and this thread is trying to read a normal user table
there even is some InnoDB SQL code within the page dump

the dump just looks like random unrelated garbage put together

oh yes, I forgot to check that it matches the `rec`
yes, it does match it

marko:

The more that I think of this, I think that the memory may never have been part of the buffer pool, but heap memory. Too bad I did not ask you to dump the buf_pool->chunks.
Yes, it must trivially be so: `rec_copy_prefix_to_dtuple()` is being executed on a buffer that btr_pcur_store_position() must have allocated. This could be related to the ~~MDEV-14837~~ fix from yesterday. Or there could have been some corruption on the index page, causing btr_pcur_store_position() to copy garbage, and to somehow miss this corruption when copying. Or there was some rogue write that corrupted the copied record prefix in the malloc() heap.
One more contributing factor could be adaptive hash index corruption, which is very unlikely, since the query did not use any index lookup.
Luckily, the transaction ID was small (0x4146); I think it starts from around 0x500 and is incremented by 2 for each transaction.

sorry, `buf_pool_ptr[0].chunks`. there can be multiple; see `srv_buf_pool_instances`. so maybe, `p *buf_pool_ptr@srv_buf_pool_instances` would do the trick.

That said, in this particular case it is now obvious that the pointer was in a `malloc()` heap, not inside the InnoDB buffer pool. The only question is: how did we manage to get the record corrupted in the heap? I think that the most plausible explanation is that it was corrupted by something doing `malloc()` and then writing outside the bounds the allocated area, corrupting the record prefix in `pcur`. (The next plausible one is that there really was a page corruption, and we somehow magically managed to copy a corrupted record prefix to the `pcur` buffer.)

(gdb) p *buf_pool_ptr@srv_buf_pool_instances

$1 = {{mutex = {m_impl = {m_lock_word = 1, m_event = 0x5602702adcf0, m_policy = {<MutexDebug<TTASEventMutex<GenericPolicy> >> = {

            _vptr.MutexDebug = 0x56026e54cfd8 <vtable for GenericPolicy<TTASEventMutex<GenericPolicy> >+16>, m_magic_n = 979585, m_context = {<latch_t> = {

                _vptr.latch_t = 0x56026e54ce78 <vtable for MutexDebug<TTASEventMutex<GenericPolicy> >::Context+16>, m_id = LATCH_ID_BUF_POOL, m_rw_lock = false, m_temp_fsp = false}, m_mutex = 0x5602702ad680,

              m_filename = 0x56026df1a128 "/home/elenst/git/10.3/storage/innobase/buf/buf0buf.cc", m_line = 6077, m_thread_id = 140675455297280}}, m_count = {m_spins = 0, m_waits = 0, m_calls = 0, m_enabled = false},

          m_id = LATCH_ID_BUF_POOL}}, m_ptr = 0x0}, zip_mutex = {m_impl = {m_lock_word = 0, m_event = 0x5602702addf0, m_policy = {<MutexDebug<TTASEventMutex<BlockMutexPolicy> >> = {

            _vptr.MutexDebug = 0x56026e54d460 <vtable for BlockMutexPolicy<TTASEventMutex<BlockMutexPolicy> >+16>, m_magic_n = 979585, m_context = {<latch_t> = {

                _vptr.latch_t = 0x56026e54d050 <vtable for MutexDebug<TTASEventMutex<BlockMutexPolicy> >::Context+16>, m_id = LATCH_ID_BUF_POOL_ZIP, m_rw_lock = false, m_temp_fsp = false}, m_mutex = 0x0, m_filename = 0x0,

              m_line = 0, m_thread_id = 18446744073709551615}}, m_count = 0x5602702ade70, m_id = LATCH_ID_BUF_POOL_ZIP}}, m_ptr = 0x0}, instance_no = 0, curr_pool_size = 134201344, LRU_old_ratio = 378, buddy_n_frames = 0,

    mutex_exit_forbidden = 0, allocator = {<No data fields>}, n_chunks = 1, n_chunks_new = 1, chunks = 0x5602702adeb0, chunks_old = 0x0, curr_size = 8191, old_size = 8191, read_ahead_area = 64, page_hash = 0x5602707adce0,

    page_hash_old = 0x0, zip_hash = 0x5602707c0150, n_pend_reads = 0, n_pend_unzip = 0, last_printout_time = 1515518825, buddy_stat = {{used = 0, relocated = 0, relocated_usec = 0}, {used = 0, relocated = 0,

        relocated_usec = 0}, {used = 0, relocated = 0, relocated_usec = 0}, {used = 0, relocated = 0, relocated_usec = 0}, {used = 0, relocated = 0, relocated_usec = 0}, {used = 0, relocated = 0, relocated_usec = 0}, {

        used = 0, relocated = 0, relocated_usec = 0}}, stat = {n_page_gets = 955220, n_pages_read = 329, n_pages_written = 41828, n_pages_created = 16616, n_ra_pages_read_rnd = 0, n_ra_pages_read = 0,

      n_ra_pages_evicted = 0, n_pages_made_young = 281, n_pages_not_made_young = 2362, LRU_bytes = 117325824, flush_list_bytes = 1998848}, old_stat = {n_page_gets = 931937, n_pages_read = 329, n_pages_written = 40950,

      n_pages_created = 16313, n_ra_pages_read_rnd = 0, n_ra_pages_read = 0, n_ra_pages_evicted = 0, n_pages_made_young = 281, n_pages_not_made_young = 2362, LRU_bytes = 117489664, flush_list_bytes = 229376},

    flush_list_mutex = {m_impl = {m_lock_word = 0, m_event = 0x5602707c01a0, m_policy = {<MutexDebug<TTASEventMutex<GenericPolicy> >> = {

            _vptr.MutexDebug = 0x56026e54cfd8 <vtable for GenericPolicy<TTASEventMutex<GenericPolicy> >+16>, m_magic_n = 979585, m_context = {<latch_t> = {

                _vptr.latch_t = 0x56026e54ce78 <vtable for MutexDebug<TTASEventMutex<GenericPolicy> >::Context+16>, m_id = LATCH_ID_FLUSH_LIST, m_rw_lock = false, m_temp_fsp = false}, m_mutex = 0x0, m_filename = 0x0,

              m_line = 0, m_thread_id = 18446744073709551615}}, m_count = {m_spins = 0, m_waits = 0, m_calls = 0, m_enabled = false}, m_id = LATCH_ID_FLUSH_LIST}}, m_ptr = 0x0}, flush_hp = {<HazardPointer> = {

        _vptr.HazardPointer = 0x56026e54d410 <vtable for FlushHp+16>, m_buf_pool = 0x5602702ad680, m_mutex = 0x5602702ad948, m_hp = 0x0}, <No data fields>}, flush_list = {count = 122, start = 0x7ff19518c000,

      end = 0x7ff1956a5c00, node = &buf_page_t::list, init = 51966}, init_flush = {0, 0, 0}, n_flush = {0, 0, 0}, no_flush = {0x5602707c02a0, 0x5602707c0320, 0x5602707c03a0}, flush_rbt = 0x0, freed_page_clock = 9784,

    try_LRU_scan = 1, free = {count = 1024, start = 0x7ff19538e200, end = 0x7ff195758a00, node = &buf_page_t::list, init = 51966}, withdraw = {count = 0, start = 0x0, end = 0x0, node = &buf_page_t::list, init = 51966},

    withdraw_target = 0, lru_hp = {<HazardPointer> = {_vptr.HazardPointer = 0x56026e54d3e8 <vtable for LRUHp+16>, m_buf_pool = 0x5602702ad680, m_mutex = 0x5602702ad680, m_hp = 0x0}, <No data fields>},

    lru_scan_itr = {<LRUHp> = {<HazardPointer> = {_vptr.HazardPointer = 0x56026e54d438 <vtable for LRUItr+16>, m_buf_pool = 0x5602702ad680, m_mutex = 0x5602702ad680, m_hp = 0x0}, <No data fields>}, <No data fields>},

    single_scan_itr = {<LRUHp> = {<HazardPointer> = {_vptr.HazardPointer = 0x56026e54d438 <vtable for LRUItr+16>, m_buf_pool = 0x5602702ad680, m_mutex = 0x5602702ad680, m_hp = 0x0}, <No data fields>}, <No data fields>},

    LRU = {count = 7161, start = 0x7ff19522a100, end = 0x7ff19538df00, node = &buf_page_t::LRU, init = 51966}, LRU_old = 0x7ff19557cc00, LRU_old_len = 2623, unzip_LRU = {count = 0, start = 0x0, end = 0x0,

      node = &buf_block_t::unzip_LRU, init = 51966}, zip_clean = {count = 0, start = 0x0, end = 0x0, node = &buf_page_t::list, init = 51966}, zip_free = {{count = 0, start = 0x0, end = 0x0, node = &buf_buddy_free_t::list,

        init = 51966}, {count = 0, start = 0x0, end = 0x0, node = &buf_buddy_free_t::list, init = 51966}, {count = 0, start = 0x0, end = 0x0, node = &buf_buddy_free_t::list, init = 51966}, {count = 0, start = 0x0,

        end = 0x0, node = &buf_buddy_free_t::list, init = 51966}, {count = 0, start = 0x0, end = 0x0, node = &buf_buddy_free_t::list, init = 51966}, {count = 0, start = 0x0, end = 0x0, node = &buf_buddy_free_t::list,

        init = 51966}}, watch = 0x5602707c0420, tmp_arr = 0x5602707c0840}}

Attachments

Issue Links

causes

MDEV-16065 Assertion `!cmp_rec_rec(cursor->old_rec, rec, offsets1, offsets2, index)' failed in btr_pcur_restore_position_func on UPDATE

Closed

is caused by

MDEV-11369 Instant add column for InnoDB

Closed

relates to

MDEV-14411 [Draft] Assertion `fil_page_type_is_index(fil_page_get_type(page))' failed in rec_get_trx_id

Open

Activity

People

Assignee:: Marko Mäkelä

Reporter:: Elena Stepanova

Votes:: 0 Vote for this issue

Watchers:: 2 Start watching this issue

Dates

Created:: 2018-01-09 18:52

Updated:: 2018-05-02 07:23

Resolved:: 2018-04-30 09:11

Git Integration

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