[MDEV-21441] Assertion: index->id == btr_page_get_index_id(page) failed in btr_cur_search_to_nth_level Created: 2020-01-08  Updated: 2020-01-08  Resolved: 2020-01-08

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.1, 10.2
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Alice Sherepa Assignee: Alice Sherepa
Resolution: Not a Bug Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-12114 install_db shows corruption for rest ... Closed

 Description   

to reproduce:

./mtr encryption.innodb-redo-badkey --mysqld=--innodb-checksum-algorithm=none

10.1 cb204e11eaf4c473ce5d5a10a21de1

 
#3  <signal handler called>
 
#4  0x00007f7672deb428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
 
#5  0x00007f7672ded02a in __GI_abort () at abort.c:89
 
#6  0x00007f766b1f6c18 in btr_cur_search_to_nth_level (index=0x7f765f86e678, level=0, tuple=0x7f765f81dab8, mode=4, latch_mode=2, cursor=0x7f767149a510, has_search_latch=0, file=0x7f766b513960 "/10.1/storage/innobase/row/row0row.cc", line=742, mtr=0x7f76613f95e0) at /10.1/storage/innobase/btr/btr0cur.cc:722
 
#7  0x00007f766b41c8dc in btr_pcur_open_low (index=0x7f765f86e678, level=0, tuple=0x7f765f81dab8, mode=4, latch_mode=2, cursor=0x7f767149a510, file=0x7f766b513960 "/10.1/storage/innobase/row/row0row.cc", line=742, mtr=0x7f76613f95e0) at /10.1/storage/innobase/include/btr0pcur.ic:440
 
#8  0x00007f766b41e47a in row_search_on_row_ref (pcur=0x7f767149a510, mode=2, table=0x7f765f8450f8, ref=0x7f765f81dab8, mtr=0x7f76613f95e0) at /10.1/storage/innobase/row/row0row.cc:742
 
#9  0x00007f766b417cf6 in row_purge_reposition_pcur (mode=2, node=0x7f767149a478, mtr=0x7f76613f95e0) at /10.1/storage/innobase/row/row0purge.cc:105
 
#10 0x00007f766b417e38 in row_purge_remove_clust_if_poss_low (node=0x7f767149a478, mode=2) at /10.1/storage/innobase/row/row0purge.cc:150
 
#11 0x00007f766b41807c in row_purge_remove_clust_if_poss (node=0x7f767149a478) at /10.1/storage/innobase/row/row0purge.cc:213
 
#12 0x00007f766b418af8 in row_purge_del_mark (node=0x7f767149a478) at /10.1/storage/innobase/row/row0purge.cc:590
 
#13 0x00007f766b4193ec in row_purge_record_func (node=0x7f767149a478, undo_rec=0x7f765f81c4e8 "\002\364\016\003\020", thr=0x7f7671415fc0, updated_extern=false) at /10.1/storage/innobase/row/row0purge.cc:860
 
#14 0x00007f766b419643 in row_purge (node=0x7f767149a478, undo_rec=0x7f765f81c4e8 "\002\364\016\003\020", thr=0x7f7671415fc0) at /10.1/storage/innobase/row/row0purge.cc:916
 
#15 0x00007f766b4198ad in row_purge_step (thr=0x7f7671415fc0) at /10.1/storage/innobase/row/row0purge.cc:994
 
#16 0x00007f766b3b8cdc in que_thr_step (thr=0x7f7671415fc0) at /10.1/storage/innobase/que/que0que.cc:1079
 
#17 0x00007f766b3b8ee0 in que_run_threads_low (thr=0x7f7671415fc0) at /10.1/storage/innobase/que/que0que.cc:1141
 
#18 0x00007f766b3b906e in que_run_threads (thr=0x7f7671415fc0) at /10.1/storage/innobase/que/que0que.cc:1182
 
#19 0x00007f766b46c6c0 in trx_purge (n_purge_threads=1, batch_size=300, truncate=false) at /10.1/storage/innobase/trx/trx0purge.cc:1230
 
#20 0x00007f766b452988 in srv_do_purge (n_threads=1, n_total_purged=0x7f76613f9d30) at /10.1/storage/innobase/srv/srv0srv.cc:2736
 
#21 0x00007f766b452eef in srv_purge_coordinator_thread (arg=0x0) at /10.1/storage/innobase/srv/srv0srv.cc:2880
 
#22 0x00007f76738126ba in start_thread (arg=0x7f76613fa700) at pthread_create.c:333
 
#23 0x00007f7672ebd41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109



 Comments   
Comment by Marko Mäkelä [ 2020-01-08 ]

The test encryption.innodb-redo-badkey is intentionally using wrong encryption key. Because of innodb_checksum_algorithm=none the corruption (after decrypting with wrong key) is not being noticed, and we can get various assertions anywhere in the code. This particular assertion is validating PAGE_INDEX_ID on the page.

Starting with 10.4, with innodb_checksum_algorithm=full_crc32 there is no separate ‘before encryption’ checksum, and it might be that we would fail to detect that a page was corrupted due to decrypting with the wrong key. But, I would think that this is extremely rare, because we really only allow one checksum in that case, unlike in other cases (where the default innodb_checksum_algorithm=crc32 would allow any variant of none,innodb,crc32).

I would tend to close this as "Not a bug", but I leave that to you. At least, it might be worth documenting that it is a bad idea to use anything else than innodb_checksum_algorithm=strict_crc32 or crc32 before 10.4.

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