Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-28569

Server crash, fatal error or assertion failures somewhere in btr_cur_compress_if_useful

Details

    Description

      The test case is for reproducing purposes only, don't put it into the regression suite as is. It is non-deterministic, run with --repeat. It currently fails for me very quickly, in 1-3 attempts on 10.5+ and slightly longer on 10.3-10.4; but it can vary on different machines and builds.

      Run with --mysqld=--innodb-page-size=4K.

      --source include/have_sequence.inc
      --source include/have_innodb.inc
      --source include/have_innodb_4k.inc
       
      CREATE TABLE t (a MULTIPOINT NOT NULL, b INT DEFAULT 0 INVISIBLE, id INT, c BINARY(220), d VARCHAR(128), PRIMARY KEY (a(9),c,id,b), SPATIAL(a), UNIQUE(id)) ENGINE=InnoDB;
      INSERT INTO t (id,c,b,a,d) SELECT seq,'',1,MULTIPOINTFromText('MULTIPOINT(0.60 0.04,0.30 0.19,0.98 0.22,0.42 0.06)'),'quxx' FROM seq_1_to_1024;
      REPLACE INTO t SELECT * FROM t;
       
      --sleep 5
       
      # Cleanup
      DROP TABLE t;
      

      10.5 debug 3fabdc3c

      mariadbd: /data/src/10.5/storage/innobase/rem/rem0cmp.cc:273: int cmp_data(ulint, ulint, const byte*, ulint, const byte*, ulint): Assertion `len1 == DATA_MBR_LEN' failed.
      220516  2:13:30 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007f9e5970f662 in __GI___assert_fail (assertion=0x5558b6d8f78e "len1 == DATA_MBR_LEN", file=0x5558b6d8f6d8 "/data/src/10.5/storage/innobase/rem/rem0cmp.cc", line=273, function=0x5558b6d8f708 "int cmp_data(ulint, ulint, const byte*, ulint, const byte*, ulint)") at assert.c:101
      #8  0x00005558b65a87c1 in cmp_data (mtype=14, prtype=3583, data1=0x7f9e00001d40 "", len1=4, data2=0x7f9e4ee0311c "", len2=4) at /data/src/10.5/storage/innobase/rem/rem0cmp.cc:273
      #9  0x00005558b65a91f9 in cmp_dtuple_rec_with_match_low (dtuple=0x7f9e00001cb8, rec=0x7f9e4ee030fc "333333\323?\\\217\302\365(\\\357?{\024\256G\341z\244?)\\\217\302\365(\314?", offsets=0x7f9e38ff6740, n_cmp=2, matched_fields=0x7f9e38ff66d8) at /data/src/10.5/storage/innobase/rem/rem0cmp.cc:411
      #10 0x00005558b6566ccd in page_cur_search_with_match (block=0x7f9e4ec1cd98, index=0x7f9e1c1cc798, tuple=0x7f9e00001cb8, mode=PAGE_CUR_LE, iup_matched_fields=0x7f9e38ff6ec8, ilow_matched_fields=0x7f9e38ff6ec0, cursor=0x7f9e00009c60, rtr_info=0x0) at /data/src/10.5/storage/innobase/page/page0cur.cc:454
      #11 0x00005558b6856a88 in page_cur_search (block=0x7f9e4ec1cd98, index=0x7f9e1c1cc798, tuple=0x7f9e00001cb8, mode=PAGE_CUR_LE, cursor=0x7f9e00009c60) at /data/src/10.5/storage/innobase/include/page0cur.inl:216
      #12 0x00005558b685c3a0 in rtr_cur_restore_position (latch_mode=34, btr_cur=0x7f9e38ff7ac0, level=2, mtr=0x7f9e38ff8150) at /data/src/10.5/storage/innobase/gis/gis0sea.cc:1369
      #13 0x00005558b6859611 in rtr_get_father_node (index=0x7f9e1c1cc798, level=2, tuple=0x7f9e00002408, sea_cur=0x7f9e38ff7ac0, btr_cur=0x7f9e38ff7410, page_no=225, mtr=0x7f9e38ff8150) at /data/src/10.5/storage/innobase/gis/gis0sea.cc:711
      #14 0x00005558b6859fd7 in rtr_page_get_father_node_ptr (offsets=0x7f9e0000e4c8, heap=0x7f9e0000e448, sea_cur=0x7f9e38ff7ac0, cursor=0x7f9e38ff7410, mtr=0x7f9e38ff8150) at /data/src/10.5/storage/innobase/gis/gis0sea.cc:845
      #15 0x00005558b685a45c in rtr_page_get_father_block (offsets=0x0, heap=0x7f9e0000e448, index=0x7f9e1c1cc798, block=0x7f9e4ec33f70, mtr=0x7f9e38ff8150, sea_cur=0x7f9e38ff7ac0, cursor=0x7f9e38ff7410) at /data/src/10.5/storage/innobase/gis/gis0sea.cc:915
      #16 0x00005558b66fe1c5 in btr_compress (cursor=0x7f9e38ff7ac0, adjust=0, mtr=0x7f9e38ff8150) at /data/src/10.5/storage/innobase/btr/btr0btr.cc:3447
      #17 0x00005558b6730702 in btr_cur_compress_if_useful (cursor=0x7f9e38ff7ac0, adjust=0, mtr=0x7f9e38ff8150) at /data/src/10.5/storage/innobase/btr/btr0cur.cc:5471
      #18 0x00005558b6732615 in btr_cur_pessimistic_delete (err=0x7f9e38ff7a64, has_reserved_extents=1, cursor=0x7f9e38ff7ac0, flags=16, rollback=false, mtr=0x7f9e38ff8150) at /data/src/10.5/storage/innobase/btr/btr0cur.cc:5901
      #19 0x00005558b685239b in rtr_node_ptr_delete (cursor=0x7f9e38ff7ac0, mtr=0x7f9e38ff8150) at /data/src/10.5/storage/innobase/gis/gis0rtree.cc:1608
      #20 0x00005558b6700d23 in btr_discard_page (cursor=0x7f9e38ff7ee0, mtr=0x7f9e38ff8150) at /data/src/10.5/storage/innobase/btr/btr0btr.cc:4072
      #21 0x00005558b673215b in btr_cur_pessimistic_delete (err=0x7f9e38ff7ed0, has_reserved_extents=0, cursor=0x7f9e38ff7ee0, flags=0, rollback=false, mtr=0x7f9e38ff8150) at /data/src/10.5/storage/innobase/btr/btr0cur.cc:5816
      #22 0x00005558b663793b in row_purge_remove_sec_if_poss_tree (node=0x5558b8e42c08, index=0x7f9e1c1cc798, entry=0x7f9e000013f8) at /data/src/10.5/storage/innobase/row/row0purge.cc:364
      #23 0x00005558b66382b8 in row_purge_remove_sec_if_poss (node=0x5558b8e42c08, index=0x7f9e1c1cc798, entry=0x7f9e000013f8) at /data/src/10.5/storage/innobase/row/row0purge.cc:575
      #24 0x00005558b66384ac in row_purge_del_mark (node=0x5558b8e42c08) at /data/src/10.5/storage/innobase/row/row0purge.cc:640
      #25 0x00005558b6639ea3 in row_purge_record_func (node=0x5558b8e42c08, undo_rec=0x7f9de8002eb0 "\002W\016\030\024", thr=0x5558b8e42a28, updated_extern=false) at /data/src/10.5/storage/innobase/row/row0purge.cc:1051
      #26 0x00005558b663a16d in row_purge (node=0x5558b8e42c08, undo_rec=0x7f9de8002eb0 "\002W\016\030\024", thr=0x5558b8e42a28) at /data/src/10.5/storage/innobase/row/row0purge.cc:1112
      #27 0x00005558b663a2e9 in row_purge_step (thr=0x5558b8e42a28) at /data/src/10.5/storage/innobase/row/row0purge.cc:1161
      #28 0x00005558b65a2617 in que_thr_step (thr=0x5558b8e42a28) at /data/src/10.5/storage/innobase/que/que0que.cc:946
      #29 0x00005558b65a28aa in que_run_threads_low (thr=0x5558b8e42a28) at /data/src/10.5/storage/innobase/que/que0que.cc:1008
      #30 0x00005558b65a2b0c in que_run_threads (thr=0x5558b8e42a28) at /data/src/10.5/storage/innobase/que/que0que.cc:1048
      #31 0x00005558b667e9f4 in srv_task_execute () at /data/src/10.5/storage/innobase/srv/srv0srv.cc:1766
      #32 0x00005558b667f2ab in purge_worker_callback () at /data/src/10.5/storage/innobase/srv/srv0srv.cc:1944
      #33 0x00005558b688ac64 in tpool::task_group::execute (this=0x5558b7eccec0 <purge_task_group>, t=0x5558b7eccc40 <purge_worker_task>) at /data/src/10.5/tpool/task_group.cc:55
      #34 0x00005558b688afba in tpool::task::execute (this=0x5558b7eccc40 <purge_worker_task>) at /data/src/10.5/tpool/task.cc:47
      #35 0x00005558b6883e2f in tpool::thread_pool_generic::worker_main (this=0x5558b8b35b50, thread_var=0x5558b8b45370) at /data/src/10.5/tpool/tpool_generic.cc:598
      #36 0x00005558b688aa04 in std::__invoke_impl<void, void (tpool::thread_pool_generic::*)(tpool::worker_data*), tpool::thread_pool_generic*, tpool::worker_data*> (__f=@0x7f9e34001418: (void (tpool::thread_pool_generic::*)(tpool::thread_pool_generic * const, tpool::worker_data *)) 0x5558b6883d9a <tpool::thread_pool_generic::worker_main(tpool::worker_data*)>, __t=@0x7f9e34001410: 0x5558b8b35b50) at /usr/include/c++/10/bits/invoke.h:73
      #37 0x00005558b688a8f4 in std::__invoke<void (tpool::thread_pool_generic::*)(tpool::worker_data*), tpool::thread_pool_generic*, tpool::worker_data*> (__fn=@0x7f9e34001418: (void (tpool::thread_pool_generic::*)(tpool::thread_pool_generic * const, tpool::worker_data *)) 0x5558b6883d9a <tpool::thread_pool_generic::worker_main(tpool::worker_data*)>) at /usr/include/c++/10/bits/invoke.h:95
      #38 0x00005558b688a827 in std::thread::_Invoker<std::tuple<void (tpool::thread_pool_generic::*)(tpool::worker_data*), tpool::thread_pool_generic*, tpool::worker_data*> >::_M_invoke<0ul, 1ul, 2ul> (this=0x7f9e34001408) at /usr/include/c++/10/thread:264
      #39 0x00005558b688a7c4 in std::thread::_Invoker<std::tuple<void (tpool::thread_pool_generic::*)(tpool::worker_data*), tpool::thread_pool_generic*, tpool::worker_data*> >::operator() (this=0x7f9e34001408) at /usr/include/c++/10/thread:271
      #40 0x00005558b688a7a8 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (tpool::thread_pool_generic::*)(tpool::worker_data*), tpool::thread_pool_generic*, tpool::worker_data*> > >::_M_run (this=0x7f9e34001400) at /usr/include/c++/10/thread:215
      #41 0x00007f9e59acced0 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
      #42 0x00007f9e59bdbea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #43 0x00007f9e597d8def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      10.5 non-debug 3fabdc3c

      #3  <signal handler called>
      #4  0x000055b9869890df in btr_cur_compress_if_useful (cursor=cursor@entry=0x7f89027fa180, adjust=adjust@entry=0, mtr=mtr@entry=0x7f89027fb130) at /data/src/10.5/storage/innobase/btr/btr0cur.cc:5459
      #5  0x000055b986a41706 in rtr_node_ptr_delete (mtr=0x7f89027fb130, cursor=0x7f89027fa180) at /data/src/10.5/storage/innobase/gis/gis0rtree.cc:1613
      #6  rtr_merge_and_update_mbr (cursor=cursor@entry=0x7f89027fa220, cursor2=cursor2@entry=0x7f89027fa180, offsets=<optimized out>, offsets2=offsets2@entry=0x7f88e40024a0, child_page=child_page@entry=0x7f89117ba000 "", mtr=mtr@entry=0x7f89027fb130) at /data/src/10.5/storage/innobase/gis/gis0rtree.cc:1592
      #7  0x000055b986974780 in btr_compress (cursor=cursor@entry=0x7f89027fa870, adjust=adjust@entry=0, mtr=mtr@entry=0x7f89027fb130) at /data/src/10.5/storage/innobase/btr/btr0btr.cc:3750
      #8  0x000055b9869890bc in btr_cur_compress_if_useful (cursor=cursor@entry=0x7f89027fa870, adjust=adjust@entry=0, mtr=mtr@entry=0x7f89027fb130) at /data/src/10.5/storage/innobase/btr/btr0cur.cc:5471
      #9  0x000055b986992f92 in btr_cur_pessimistic_delete (err=err@entry=0x7f89027fa79c, has_reserved_extents=has_reserved_extents@entry=1, cursor=cursor@entry=0x7f89027fa870, flags=flags@entry=16, rollback=rollback@entry=false, mtr=mtr@entry=0x7f89027fb130) at /data/src/10.5/storage/innobase/btr/btr0cur.cc:5901
      #10 0x000055b986a3f03e in rtr_node_ptr_delete (cursor=cursor@entry=0x7f89027fa870, mtr=mtr@entry=0x7f89027fb130) at /data/src/10.5/storage/innobase/gis/gis0rtree.cc:1608
      #11 0x000055b986974643 in btr_compress (cursor=cursor@entry=0x7f89027faec0, adjust=adjust@entry=0, mtr=mtr@entry=0x7f89027fb130) at /data/src/10.5/storage/innobase/btr/btr0btr.cc:3595
      #12 0x000055b9869890bc in btr_cur_compress_if_useful (cursor=cursor@entry=0x7f89027faec0, adjust=adjust@entry=0, mtr=mtr@entry=0x7f89027fb130) at /data/src/10.5/storage/innobase/btr/btr0cur.cc:5471
      #13 0x000055b986992f92 in btr_cur_pessimistic_delete (err=err@entry=0x7f89027fae90, has_reserved_extents=has_reserved_extents@entry=0, cursor=cursor@entry=0x7f89027faec0, flags=flags@entry=0, rollback=rollback@entry=false, mtr=mtr@entry=0x7f89027fb130) at /data/src/10.5/storage/innobase/btr/btr0cur.cc:5901
      #14 0x000055b9869077ea in row_purge_remove_sec_if_poss_tree (node=0x55b989b78de0, index=0x7f88601a3540, entry=0x7f88e4001060) at /data/src/10.5/storage/innobase/row/row0purge.cc:364
      #15 0x000055b986907fdc in row_purge_remove_sec_if_poss (entry=0x7f88e4001060, index=<optimized out>, node=0x55b989b78de0) at /data/src/10.5/storage/innobase/row/row0purge.cc:575
      #16 row_purge_del_mark (node=0x55b989b78de0) at /data/src/10.5/storage/innobase/row/row0purge.cc:640
      #17 row_purge_record_func (node=0x55b989b78de0, undo_rec=0x7f88fc0c4660 "\002W\016\n\024", thr=0x55b989b78c00, updated_extern=<optimized out>) at /data/src/10.5/storage/innobase/row/row0purge.cc:1051
      #18 0x000055b9869089c2 in row_purge (thr=0x55b989b78c00, undo_rec=0x7f88fc0c4660 "\002W\016\n\024", node=0x55b989b78de0) at /data/src/10.5/storage/innobase/row/row0purge.cc:1112
      #19 row_purge_step (thr=thr@entry=0x55b989b78c00) at /data/src/10.5/storage/innobase/row/row0purge.cc:1161
      #20 0x000055b9868c7f06 in que_thr_step (thr=0x7f89027fbc80) at /data/src/10.5/storage/innobase/que/que0que.cc:946
      #21 que_run_threads_low (thr=0x7f89027fbc80) at /data/src/10.5/storage/innobase/que/que0que.cc:1008
      #22 que_run_threads (thr=thr@entry=0x55b989b78c00) at /data/src/10.5/storage/innobase/que/que0que.cc:1048
      #23 0x000055b9869288b7 in srv_task_execute () at /data/src/10.5/storage/innobase/srv/srv0srv.cc:1766
      #24 purge_worker_callback () at /data/src/10.5/storage/innobase/srv/srv0srv.cc:1944
      #25 0x000055b986a68fd9 in tpool::task_group::execute (this=0x55b987d5d760 <purge_task_group>, t=0x55b987d3f920 <purge_worker_task>) at /data/src/10.5/tpool/task_group.cc:55
      #26 0x000055b986a6822f in tpool::thread_pool_generic::worker_main (this=0x55b989947570, thread_var=0x55b989957010) at /data/src/10.5/tpool/tpool_generic.cc:598
      #27 0x00007f8918253ed0 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
      #28 0x00007f8918360ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #29 0x00007f8917f77def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      On 10.3-10.4 the failure is similar to MDEV-27675:

      10.3 debug 8c28b27f

      mysqld: /data/src/10.3/storage/innobase/gis/gis0sea.cc:722: void rtr_get_father_node(dict_index_t*, ulint, const dtuple_t*, btr_cur_t*, btr_cur_t*, ulint, mtr_t*): Assertion `ret' failed.
       
      #7  0x00007f9aefccf662 in __GI___assert_fail (assertion=0x5579179a4367 "ret", file=0x5579179a3d70 "/data/src/10.3/storage/innobase/gis/gis0sea.cc", line=722, function=0x5579179a4300 "void rtr_get_father_node(dict_index_t*, ulint, const dtuple_t*, btr_cur_t*, btr_cur_t*, ulint, mtr_t*)") at assert.c:101
      #8  0x00005579173d2769 in rtr_get_father_node (index=0x7f9a980dfa20, level=2, tuple=0x7f9aa400add0, sea_cur=0x7f9abb7fca00, btr_cur=0x7f9abb7fc260, page_no=226, mtr=0x7f9abb7fd300) at /data/src/10.3/storage/innobase/gis/gis0sea.cc:722
      #9  0x00005579173d30bd in rtr_page_get_father_node_ptr (offsets=0x7f9aa400e5d0, heap=0x7f9aa400e550, sea_cur=0x7f9abb7fca00, cursor=0x7f9abb7fc260, mtr=0x7f9abb7fd300) at /data/src/10.3/storage/innobase/gis/gis0sea.cc:850
      #10 0x00005579173d354c in rtr_page_get_father_block (offsets=0x0, heap=0x7f9aa400e550, index=0x7f9a980dfa20, block=0x7f9ae909d780, mtr=0x7f9abb7fd300, sea_cur=0x7f9abb7fca00, cursor=0x7f9abb7fc260) at /data/src/10.3/storage/innobase/gis/gis0sea.cc:920
      #11 0x000055791724d087 in btr_compress (cursor=0x7f9abb7fca00, adjust=0, mtr=0x7f9abb7fd300) at /data/src/10.3/storage/innobase/btr/btr0btr.cc:3581
      #12 0x000055791727e42c in btr_cur_compress_if_useful (cursor=0x7f9abb7fca00, adjust=0, mtr=0x7f9abb7fd300) at /data/src/10.3/storage/innobase/btr/btr0cur.cc:5467
      #13 0x0000557917280387 in btr_cur_pessimistic_delete (err=0x7f9abb7fc8c4, has_reserved_extents=1, cursor=0x7f9abb7fca00, flags=16, rollback=false, mtr=0x7f9abb7fd300) at /data/src/10.3/storage/innobase/btr/btr0cur.cc:5903
      #14 0x00005579173cb335 in rtr_node_ptr_delete (cursor=0x7f9abb7fca00, mtr=0x7f9abb7fd300) at /data/src/10.3/storage/innobase/gis/gis0rtree.cc:1716
      #15 0x000055791724da2e in btr_compress (cursor=0x7f9abb7fd090, adjust=0, mtr=0x7f9abb7fd300) at /data/src/10.3/storage/innobase/btr/btr0btr.cc:3755
      #16 0x000055791727e42c in btr_cur_compress_if_useful (cursor=0x7f9abb7fd090, adjust=0, mtr=0x7f9abb7fd300) at /data/src/10.3/storage/innobase/btr/btr0cur.cc:5467
      #17 0x0000557917280387 in btr_cur_pessimistic_delete (err=0x7f9abb7fd080, has_reserved_extents=0, cursor=0x7f9abb7fd090, flags=0, rollback=false, mtr=0x7f9abb7fd300) at /data/src/10.3/storage/innobase/btr/btr0cur.cc:5903
      #18 0x0000557917174f86 in row_purge_remove_sec_if_poss_tree (node=0x557919119910, index=0x7f9a980dfa20, entry=0x7f9aa400c400) at /data/src/10.3/storage/innobase/row/row0purge.cc:470
      #19 0x0000557917175b03 in row_purge_remove_sec_if_poss (node=0x557919119910, index=0x7f9a980dfa20, entry=0x7f9aa400c400) at /data/src/10.3/storage/innobase/row/row0purge.cc:704
      #20 0x0000557917175cfa in row_purge_del_mark (node=0x557919119910) at /data/src/10.3/storage/innobase/row/row0purge.cc:769
      #21 0x00005579171778db in row_purge_record_func (node=0x557919119910, undo_rec=0x7f9aac04ae60 "\002X\016\201\376\026", thr=0x557919119490, updated_extern=false) at /data/src/10.3/storage/innobase/row/row0purge.cc:1195
      #22 0x0000557917177be5 in row_purge (node=0x557919119910, undo_rec=0x7f9aac04ae60 "\002X\016\201\376\026", thr=0x557919119490) at /data/src/10.3/storage/innobase/row/row0purge.cc:1261
      #23 0x0000557917177f7d in row_purge_step (thr=0x557919119490) at /data/src/10.3/storage/innobase/row/row0purge.cc:1339
      #24 0x00005579170e30c7 in que_thr_step (thr=0x557919119490) at /data/src/10.3/storage/innobase/que/que0que.cc:1038
      #25 0x00005579170e335a in que_run_threads_low (thr=0x557919119490) at /data/src/10.3/storage/innobase/que/que0que.cc:1100
      #26 0x00005579170e35bc in que_run_threads (thr=0x557919119490) at /data/src/10.3/storage/innobase/que/que0que.cc:1140
      #27 0x00005579171cd318 in srv_task_execute (slot=0x557917ebfab0 <srv_sys+1264>) at /data/src/10.3/storage/innobase/srv/srv0srv.cc:2456
      #28 0x00005579171cd597 in srv_worker_thread (arg=0x0) at /data/src/10.3/storage/innobase/srv/srv0srv.cc:2511
      #29 0x00007f9aefe68ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #30 0x00007f9aefd98def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      10.3 non-debug 8c28b27f

      2022-05-16  2:14:55 3 [ERROR] [FATAL] InnoDB: Corruption of index `a` of table `test`.`t` parent page 229 child page 317; child COMPACT RECORD(info_bits=0, 2 fields): {[32]333333 ?\   (\ ?{  G z ?)\   ( ?(0x333333333333D33F5C8FC2F5285CEF3F7B14AE47E17AA43F295C8FC2F528CC3F),[4]    (0x00000018)}; parent COMPACT RECORD(info_bits=0, 2 fields): {[32]333333 ?\   (\ ?{  G z ?)\   ( ?(0x333333333333D33F5C8FC2F5285CEF3F7B14AE47E17AA43F295C8FC2F528CC3F),[4]    (0x00000018)}. You should dump + drop + reimport the table to fix the corruption. If the crash happens at database startup, see https://mariadb.com/kb/en/library/innodb-recovery-modes/ about forcing recovery. Then dump + drop + reimport.
      220516  2:14:55 [ERROR] mysqld got signal 6 ;
       
      #6  0x000055c2f4f6f3c3 in ib::fatal::~fatal (this=<optimized out>, __in_chrg=<optimized out>) at /data/src/10.3/storage/innobase/ut/ut0ut.cc:606
      #7  0x000055c2f4f90d90 in rtr_page_get_father_node_ptr (offsets=0x7f5a500101a8, heap=<optimized out>, sea_cur=<optimized out>, cursor=<optimized out>, mtr=<optimized out>) at /data/src/10.3/storage/innobase/include/ut0ut.h:356
      #8  0x000055c2f554bf2e in btr_compress (cursor=cursor@entry=0x7f5a63ffda40, adjust=adjust@entry=0, mtr=mtr@entry=0x7f5a63ffe150) at /data/src/10.3/storage/innobase/btr/btr0btr.cc:3581
      #9  0x000055c2f555b34e in btr_cur_compress_if_useful (cursor=cursor@entry=0x7f5a63ffda40, adjust=adjust@entry=0, mtr=mtr@entry=0x7f5a63ffe150) at /data/src/10.3/storage/innobase/btr/btr0cur.cc:5467
      #10 0x000055c2f561d7dd in rtr_node_ptr_delete (cursor=0x7f5a63ffda40, mtr=0x7f5a63ffe150) at /data/src/10.3/storage/innobase/gis/gis0rtree.cc:1721
      #11 0x000055c2f5547115 in btr_discard_page (cursor=cursor@entry=0x7f5a63ffdee0, mtr=mtr@entry=0x7f5a63ffe150) at /data/src/10.3/storage/innobase/btr/btr0btr.cc:4230
      #12 0x000055c2f5563bc5 in btr_cur_pessimistic_delete (err=err@entry=0x7f5a63ffdeb0, has_reserved_extents=has_reserved_extents@entry=0, cursor=cursor@entry=0x7f5a63ffdee0, flags=flags@entry=0, rollback=rollback@entry=false, mtr=mtr@entry=0x7f5a63ffe150) at /data/src/10.3/storage/innobase/btr/btr0cur.cc:5808
      #13 0x000055c2f54df07a in row_purge_remove_sec_if_poss_tree (node=0x55c2f7466288, index=0x7f5a3c169f98, entry=0x7f5a5000cf08) at /data/src/10.3/storage/innobase/row/row0purge.cc:470
      #14 0x000055c2f54df89e in row_purge_remove_sec_if_poss (entry=0x7f5a5000cf08, index=<optimized out>, node=0x55c2f7466288) at /data/src/10.3/storage/innobase/row/row0purge.cc:704
      #15 row_purge_del_mark (node=0x55c2f7466288) at /data/src/10.3/storage/innobase/row/row0purge.cc:769
      #16 row_purge_record_func (node=0x55c2f7466288, undo_rec=0x7f5a5c096740 "\002X\016\204\212\024", thr=0x55c2f7465e80, updated_extern=<optimized out>) at /data/src/10.3/storage/innobase/row/row0purge.cc:1195
      #17 0x000055c2f54e06ab in row_purge (thr=0x55c2f7465e80, undo_rec=0x7f5a5c096740 "\002X\016\204\212\024", node=0x55c2f7466288) at /data/src/10.3/storage/innobase/row/row0purge.cc:1261
      #18 row_purge_step (thr=thr@entry=0x55c2f7465e80) at /data/src/10.3/storage/innobase/row/row0purge.cc:1339
      #19 0x000055c2f54a4a59 in que_thr_step (thr=0x55c2f7466288) at /data/src/10.3/storage/innobase/que/que0que.cc:1038
      #20 que_run_threads_low (thr=0x55c2f7466288) at /data/src/10.3/storage/innobase/que/que0que.cc:1100
      #21 que_run_threads (thr=thr@entry=0x55c2f7465e80) at /data/src/10.3/storage/innobase/que/que0que.cc:1140
      #22 0x000055c2f5506b35 in srv_task_execute () at /data/src/10.3/storage/innobase/srv/srv0srv.cc:2456
      #23 srv_worker_thread (arg=<optimized out>) at /data/src/10.3/storage/innobase/srv/srv0srv.cc:2511
      #24 0x00007f5a8c26bea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
      #25 0x00007f5a8c19bdef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      

      The test case is not applicable to 10.2 due to the use of an invisible column (which I couldn't get rid of).

      Attachments

        Issue Links

          Activity

            The assertion failure is triggered during a page merge that occurs during the purge of history. A record of 2 fields is being compared: the minimum bounding rectangle (MBR) in the first field and the 32-bit child page number in the second field. The assertion fails on the second field. Normally, child page numbers are never compared in that function, but SPATIAL INDEX appears to make an exception.

            For some reason, I did not get a crash when I added BEGIN before the INSERT and ROLLBACK after the REPLACE. That should have triggered a similar shrinking of the index tree.

            marko Marko Mäkelä added a comment - The assertion failure is triggered during a page merge that occurs during the purge of history. A record of 2 fields is being compared: the minimum bounding rectangle (MBR) in the first field and the 32-bit child page number in the second field. The assertion fails on the second field. Normally, child page numbers are never compared in that function, but SPATIAL INDEX appears to make an exception. For some reason, I did not get a crash when I added BEGIN before the INSERT and ROLLBACK after the REPLACE . That should have triggered a similar shrinking of the index tree.

            I debugged this a little further. Here is my test case:

            --source include/have_sequence.inc
            --source include/innodb_page_size.inc
             
            SET @save_frequency=@@GLOBAL.innodb_purge_rseg_truncate_frequency;
            SET GLOBAL innodb_purge_rseg_truncate_frequency=1;
             
            CREATE TABLE t (a MULTIPOINT NOT NULL, b INT DEFAULT 0 INVISIBLE, id INT, c BINARY(220), d VARCHAR(128), PRIMARY KEY (a(9),c,id,b), SPATIAL(a), UNIQUE(id)) ENGINE=InnoDB;
             
            INSERT INTO t (id,c,b,a,d) SELECT seq,'',1,MULTIPOINTFromText('MULTIPOINT(0.60 0.04,0.30 0.19,0.98 0.22,0.42 0.06)'),'quxx' FROM seq_1_to_1024;
             
            REPLACE INTO t SELECT * FROM t;
            --source include/wait_all_purged.inc
             
            SET GLOBAL innodb_purge_rseg_truncate_frequency=@save_frequency;
            DROP TABLE t;
            

            As far as I can tell, the problem is that rtr_cur_restore_position() will incorrectly copy the type of the column a and use it as the node pointer column’s type.

            btr_pcur_store_position() always seems to use 2 fields in spatial indexes: the minimum bounding rectangle (MBR) and the child page number. But, rtr_cur_restore_position() fails to assert that r_cursor->old_n_fields is always 2. Some code cleanup could be done as part of fixing this. Here is one suggestion; possibly we should have a completely separate function for the rare SPATIAL INDEX case.

            diff --git a/storage/innobase/dict/dict0dict.cc b/storage/innobase/dict/dict0dict.cc
            index be2d3517547..d0d057fbafb 100644
            --- a/storage/innobase/dict/dict0dict.cc
            +++ b/storage/innobase/dict/dict0dict.cc
            @@ -2392,26 +2392,27 @@ dict_index_copy_types(
             	ulint			n_fields)	/*!< in: number of
             						field types to copy */
             {
            -	ulint		i;
            +  ut_ad(n_fields <= tuple->n_fields);
             
            -	if (dict_index_is_ibuf(index)) {
            -		dtuple_set_types_binary(tuple, n_fields);
            +  if (index->is_ibuf())
            +  {
            +    dtuple_set_types_binary(tuple, n_fields);
            +    return;
            +  }
             
            -		return;
            -	}
            +  ut_ad(n_fields <= index->n_def);
             
            -	for (i = 0; i < n_fields; i++) {
            -		const dict_field_t*	ifield;
            -		dtype_t*		dfield_type;
            +  ulint i= 0;
            +  if (index->is_spatial())
            +  {
            +    dict_col_copy_type(&index->fields[0]->col, &tuple->fields[0].type);
            +    i= 1;
            +    if (DATA_GEOMETRY_MTYPE(tuple->fields[0].type.mtype))
            +      tuple->fields[0].type.prtype|= DATA_GIS_MBR;
            +  }
             
            -		ifield = dict_index_get_nth_field(index, i);
            -		dfield_type = dfield_get_type(dtuple_get_nth_field(tuple, i));
            -		dict_col_copy_type(dict_field_get_col(ifield), dfield_type);
            -		if (dict_index_is_spatial(index)
            -		    && DATA_GEOMETRY_MTYPE(dfield_type->mtype)) {
            -			dfield_type->prtype |= DATA_GIS_MBR;
            -		}
            -	}
            +  for (; i < n_fields; i++)
            +    dict_col_copy_type(&index->fields[i]->col, &tuple->fields[i].type);
             }
             
             /** Copies types of virtual columns contained in table to tuple and sets all
            

            Note: There is another function cmp_rec_rec() that is comparing two records, instead of comparing a record and a tuple. That function is handling spatial indexes as a special case (mtype=DATA_SYS_CHILD).

            marko Marko Mäkelä added a comment - I debugged this a little further. Here is my test case: --source include/have_sequence.inc --source include/innodb_page_size.inc   SET @save_frequency=@@ GLOBAL .innodb_purge_rseg_truncate_frequency; SET GLOBAL innodb_purge_rseg_truncate_frequency=1;   CREATE TABLE t (a MULTIPOINT NOT NULL , b INT DEFAULT 0 INVISIBLE, id INT , c BINARY (220), d VARCHAR (128), PRIMARY KEY (a(9),c,id,b), SPATIAL(a), UNIQUE (id)) ENGINE=InnoDB;   INSERT INTO t (id,c,b,a,d) SELECT seq, '' ,1,MULTIPOINTFromText( 'MULTIPOINT(0.60 0.04,0.30 0.19,0.98 0.22,0.42 0.06)' ), 'quxx' FROM seq_1_to_1024;   REPLACE INTO t SELECT * FROM t; --source include/wait_all_purged.inc   SET GLOBAL innodb_purge_rseg_truncate_frequency=@save_frequency; DROP TABLE t; As far as I can tell, the problem is that rtr_cur_restore_position() will incorrectly copy the type of the column a and use it as the node pointer column’s type. btr_pcur_store_position() always seems to use 2 fields in spatial indexes: the minimum bounding rectangle (MBR) and the child page number. But, rtr_cur_restore_position() fails to assert that r_cursor->old_n_fields is always 2. Some code cleanup could be done as part of fixing this. Here is one suggestion; possibly we should have a completely separate function for the rare SPATIAL INDEX case. diff --git a/storage/innobase/dict/dict0dict.cc b/storage/innobase/dict/dict0dict.cc index be2d3517547..d0d057fbafb 100644 --- a/storage/innobase/dict/dict0dict.cc +++ b/storage/innobase/dict/dict0dict.cc @@ -2392,26 +2392,27 @@ dict_index_copy_types( ulint n_fields) /*!< in: number of field types to copy */ { - ulint i; + ut_ad(n_fields <= tuple->n_fields); - if (dict_index_is_ibuf(index)) { - dtuple_set_types_binary(tuple, n_fields); + if (index->is_ibuf()) + { + dtuple_set_types_binary(tuple, n_fields); + return; + } - return; - } + ut_ad(n_fields <= index->n_def); - for (i = 0; i < n_fields; i++) { - const dict_field_t* ifield; - dtype_t* dfield_type; + ulint i= 0; + if (index->is_spatial()) + { + dict_col_copy_type(&index->fields[0]->col, &tuple->fields[0].type); + i= 1; + if (DATA_GEOMETRY_MTYPE(tuple->fields[0].type.mtype)) + tuple->fields[0].type.prtype|= DATA_GIS_MBR; + } - ifield = dict_index_get_nth_field(index, i); - dfield_type = dfield_get_type(dtuple_get_nth_field(tuple, i)); - dict_col_copy_type(dict_field_get_col(ifield), dfield_type); - if (dict_index_is_spatial(index) - && DATA_GEOMETRY_MTYPE(dfield_type->mtype)) { - dfield_type->prtype |= DATA_GIS_MBR; - } - } + for (; i < n_fields; i++) + dict_col_copy_type(&index->fields[i]->col, &tuple->fields[i].type); } /** Copies types of virtual columns contained in table to tuple and sets all Note: There is another function cmp_rec_rec() that is comparing two records, instead of comparing a record and a tuple. That function is handling spatial indexes as a special case ( mtype=DATA_SYS_CHILD ).

            I think that this particular assertion can only fail when the first column in the PRIMARY KEY is a geometry column. This bug might have no impact as long as the first (or only) column in the PRIMARY KEY is an integer or binary column. In all other cases, something bad might happen to the SPATIAL INDEX.

            marko Marko Mäkelä added a comment - I think that this particular assertion can only fail when the first column in the PRIMARY KEY is a geometry column. This bug might have no impact as long as the first (or only) column in the PRIMARY KEY is an integer or binary column. In all other cases, something bad might happen to the SPATIAL INDEX .

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

            julien.fritsch Julien Fritsch added a comment - Automated message: ---------------------------- Since this issue has not been updated since 6 weeks, it's time to move it back to Stalled.
            JIraAutomate JiraAutomate added a comment -

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

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

            People

              vlad.lesin Vladislav Lesin
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

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