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

Assertion "inited==NONE" failed in handler::ha_index_init on the slave during UPDATE

Details

    Description

      Reproducible on 10.5, with Myisam, not with InnoDB.

      source include/master-slave.inc;
      		 
       
      		 
      create table t1 (i1 int, a1 text, unique key i1 (a1)) engine=myisam;
      		 
      insert into t1 values (1,1);
      		 
      update t1 set a1 = 'd' limit 1;
      		 
       
      		 
      sync_slave_with_master;
      		 
      connection slave;
      		 
       
      		 
      connection master;
      		 
      drop table t1;
      		 
       
      		 
      --source include/rpl_end.inc

      10.5 8569dac1ec9f6853a0b2f3

      		 
      #3  <signal handler called>
      		 
      #4  0x00007fb74811b428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
      		 
      #5  0x00007fb74811d02a in __GI_abort () at abort.c:89
      		 
      #6  0x00007fb748113bd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x563f42ef17d9 "inited==NONE", file=file@entry=0x563f42ef17a8 "/10.5/sql/handler.h", line=line@entry=3323, function=function@entry=0x563f42ef5960 <handler::ha_index_init(unsigned int, bool)::__PRETTY_FUNCTION__> "int handler::ha_index_init(uint, bool)") at assert.c:92
      		 
      #7  0x00007fb748113c82 in __GI___assert_fail (assertion=0x563f42ef17d9 "inited==NONE", file=0x563f42ef17a8 "/10.5/sql/handler.h", line=3323, function=0x563f42ef5960 <handler::ha_index_init(unsigned int, bool)::__PRETTY_FUNCTION__> "int handler::ha_index_init(uint, bool)") at assert.c:101
      		 
      #8  0x0000563f420913dd in handler::ha_index_init (this=0x7fb6f0038740, idx=0, sorted=false) at /10.5/sql/handler.h:3323
      		 
      #9  0x0000563f424b441a in handler::check_duplicate_long_entry_key (this=0x7fb6f0038740, new_rec=0x7fb6f00382d8 "\370\001", key_no=0) at /10.5/sql/handler.cc:6629
      		 
      #10 0x0000563f424b4df8 in handler::check_duplicate_long_entries_update (this=0x7fb6f0038740, new_rec=0x7fb6f00382d8 "\370\001") at /10.5/sql/handler.cc:6761
      		 
      #11 0x0000563f424b61ec in handler::ha_update_row (this=0x7fb6f0038740, old_data=0x7fb6f00382f0 "\370\001", new_data=0x7fb6f00382d8 "\370\001") at /10.5/sql/handler.cc:7031
      		 
      #12 0x0000563f4261de7f in Update_rows_log_event::do_exec_row (this=0x7fb6f0960af8, rgi=0x7fb6f0000a90) at /10.5/sql/log_event_server.cc:8325
      		 
      #13 0x0000563f426158ed in Rows_log_event::do_apply_event (this=0x7fb6f0960af8, rgi=0x7fb6f0000a90) at /10.5/sql/log_event_server.cc:5650
      		 
      #14 0x0000563f42045df5 in Log_event::apply_event (this=0x7fb6f0960af8, rgi=0x7fb6f0000a90) at /10.5/sql/log_event.h:1496
      		 
      #15 0x0000563f420388e4 in apply_event_and_update_pos_apply (ev=0x7fb6f0960af8, thd=0x7fb6f0001598, rgi=0x7fb6f0000a90, reason=0) at /10.5/sql/slave.cc:4003
      		 
      #16 0x0000563f42038ec7 in apply_event_and_update_pos (ev=0x7fb6f0960af8, thd=0x7fb6f0001598, rgi=0x7fb6f0000a90) at /10.5/sql/slave.cc:4165
      		 
      #17 0x0000563f42039880 in exec_relay_log_event (thd=0x7fb6f0001598, rli=0x563f46015458, serial_rgi=0x7fb6f0000a90) at /10.5/sql/slave.cc:4486
      		 
      #18 0x0000563f4203d1b8 in handle_slave_sql (arg=0x563f46013790) at /10.5/sql/slave.cc:5659
      		 
      #19 0x0000563f42743efc in pfs_spawn_thread (arg=0x7fb7041f96e8) at /10.5/storage/perfschema/pfs.cc:2201
      		 
      #20 0x00007fb748f5c6ba in start_thread (arg=0x7fb73c2f3700) at pthread_create.c:333
      		 
      #21 0x00007fb7481ed41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

      Attachments

        Issue Links

          duplicates

          Bug - A problem which impairs or prevents the functions of the product. MDEV-22847 Server crashes in handler::check_duplicate_long_entry_key upon executing row event

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed
          relates to

          Task - A task that needs to be done. MDEV-371 Unique indexes for blobs

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-18720 Assertion `inited==NONE' failed in ha_index_init upon update on versioned table with key on blob

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            sachin.setiya.007 Sachin Setiya (Inactive) added a comment -

            Fails with 10.4 also (after completing MDEV-22747 )

            sachin.setiya.007 Sachin Setiya (Inactive) added a comment - Fails with 10.4 also (after completing MDEV-22747 )
            sachin.setiya.007 Sachin Setiya (Inactive) added a comment -

            It fails even without update

            source include/master-slave.inc;
            		 
             
            create table t1 (i1 int, a1 text unique)engine=myisam;
            		 
            insert into t1 values (1,1);
            		 
            sync_slave_with_master;
            		 
            connection slave;
            		 
             
            connection master;
            		 
            drop table t1;
            		 
             
            --source include/rpl_end.inc

            sachin.setiya.007 Sachin Setiya (Inactive) added a comment - It fails even without update source include/master-slave.inc; create table t1 (i1 int, a1 text unique)engine=myisam; insert into t1 values (1,1); sync_slave_with_master; connection slave; connection master; drop table t1; --source include/rpl_end.inc
            sachin.setiya.007 Sachin Setiya (Inactive) added a comment -

            Patch branch bb-10.4-sachin2 and bb-10.5-sachin

            sachin.setiya.007 Sachin Setiya (Inactive) added a comment - Patch branch bb-10.4-sachin2 and bb-10.5-sachin
            sachin.setiya.007 Sachin Setiya (Inactive) added a comment -

            Ideally it should fail for innodb also , needs debugging

            sachin.setiya.007 Sachin Setiya (Inactive) added a comment - Ideally it should fail for innodb also , needs debugging
            elenst Elena Stepanova added a comment -

            MDEV-22847 is marked as a duplicate of this one.
            Some notes:

            • Representation of the failure without UPDATE is not identical to the initially reported one. The reported one is a debug assertion which happens in the mixed combination (apparently because only UPDATE makes mixed replication switch to RBR, while INSERT doesn't). The reduced version of the test case without UPDATE causes SIGSEGV in the row combination of the test, and it affects both debug and non-debug builds. Here is the stack trace from it: 

              #3  <signal handler called>
              		 
              #4  __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:286
              		 
              #5  0x0000560680c94788 in handler::check_duplicate_long_entry_key (this=0x7f22cc038e00, new_rec=0x7f22cc035898 "\370\001", key_no=0) at /data/src/10.5/sql/handler.cc:6645
              		 
              #6  0x0000560680c94fd1 in handler::check_duplicate_long_entries (this=0x7f22cc038e00, new_rec=0x7f22cc035898 "\370\001") at /data/src/10.5/sql/handler.cc:6726
              		 
              #7  0x0000560680c95dc9 in handler::ha_write_row (this=0x7f22cc038e00, buf=0x7f22cc035898 "\370\001") at /data/src/10.5/sql/handler.cc:6996
              		 
              #8  0x0000560680df8af2 in Rows_log_event::write_row (this=0x7f22cc033f28, rgi=0x7f22cc000a90, overwrite=false) at /data/src/10.5/sql/log_event_server.cc:7260
              		 
              #9  0x0000560680df9747 in Write_rows_log_event::do_exec_row (this=0x7f22cc033f28, rgi=0x7f22cc000a90) at /data/src/10.5/sql/log_event_server.cc:7480
              		 
              #10 0x0000560680df33d5 in Rows_log_event::do_apply_event (this=0x7f22cc033f28, rgi=0x7f22cc000a90) at /data/src/10.5/sql/log_event_server.cc:5650
              		 
              #11 0x0000560680829feb in Log_event::apply_event (this=0x7f22cc033f28, rgi=0x7f22cc000a90) at /data/src/10.5/sql/log_event.h:1496
              		 
              #12 0x000056068081ca58 in apply_event_and_update_pos_apply (ev=0x7f22cc033f28, thd=0x7f22cc001598, rgi=0x7f22cc000a90, reason=0) at /data/src/10.5/sql/slave.cc:4003
              		 
              #13 0x000056068081d03e in apply_event_and_update_pos (ev=0x7f22cc033f28, thd=0x7f22cc001598, rgi=0x7f22cc000a90) at /data/src/10.5/sql/slave.cc:4165
              		 
              #14 0x000056068081d990 in exec_relay_log_event (thd=0x7f22cc001598, rli=0x56068406f6d8, serial_rgi=0x7f22cc000a90) at /data/src/10.5/sql/slave.cc:4482
              		 
              #15 0x00005606808212fd in handle_slave_sql (arg=0x56068406da10) at /data/src/10.5/sql/slave.cc:5659
              		 
              #16 0x0000560681002b56 in pfs_spawn_thread (arg=0x7f22e01face8) at /data/src/10.5/storage/perfschema/pfs.cc:2201
              		 
              #17 0x00007f23150824a4 in start_thread (arg=0x7f230c312700) at pthread_create.c:456
              		 
              #18 0x00007f23131b6d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

            • both variations are reproducible with InnoDB as well, with the same test cases. I don't know what happened when you tried, please double-check.
            • it fails on 10.4 after completing MDEV-22747 because one of the commits you are backporting introduced the failure. This one: 

              commit 0515577d128318e1b62511846d88d0c56226168d
              		 
              Author: Sergei Golubchik
              		 
              Date: Thu Mar 5 19:19:57 2020 +0100
              		 
               
              		 
              cleanup: prepare "update_handler" for WITHOUT OVERLAPS

            elenst Elena Stepanova added a comment - MDEV-22847 is marked as a duplicate of this one. Some notes: Representation of the failure without UPDATE is not identical to the initially reported one. The reported one is a debug assertion which happens in the mixed combination (apparently because only UPDATE makes mixed replication switch to RBR, while INSERT doesn't). The reduced version of the test case without UPDATE causes SIGSEGV in the row combination of the test, and it affects both debug and non-debug builds. Here is the stack trace from it: #3 <signal handler called> #4 __memmove_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:286 #5 0x0000560680c94788 in handler::check_duplicate_long_entry_key (this=0x7f22cc038e00, new_rec=0x7f22cc035898 "\370\001", key_no=0) at /data/src/10.5/sql/handler.cc:6645 #6 0x0000560680c94fd1 in handler::check_duplicate_long_entries (this=0x7f22cc038e00, new_rec=0x7f22cc035898 "\370\001") at /data/src/10.5/sql/handler.cc:6726 #7 0x0000560680c95dc9 in handler::ha_write_row (this=0x7f22cc038e00, buf=0x7f22cc035898 "\370\001") at /data/src/10.5/sql/handler.cc:6996 #8 0x0000560680df8af2 in Rows_log_event::write_row (this=0x7f22cc033f28, rgi=0x7f22cc000a90, overwrite=false) at /data/src/10.5/sql/log_event_server.cc:7260 #9 0x0000560680df9747 in Write_rows_log_event::do_exec_row (this=0x7f22cc033f28, rgi=0x7f22cc000a90) at /data/src/10.5/sql/log_event_server.cc:7480 #10 0x0000560680df33d5 in Rows_log_event::do_apply_event (this=0x7f22cc033f28, rgi=0x7f22cc000a90) at /data/src/10.5/sql/log_event_server.cc:5650 #11 0x0000560680829feb in Log_event::apply_event (this=0x7f22cc033f28, rgi=0x7f22cc000a90) at /data/src/10.5/sql/log_event.h:1496 #12 0x000056068081ca58 in apply_event_and_update_pos_apply (ev=0x7f22cc033f28, thd=0x7f22cc001598, rgi=0x7f22cc000a90, reason=0) at /data/src/10.5/sql/slave.cc:4003 #13 0x000056068081d03e in apply_event_and_update_pos (ev=0x7f22cc033f28, thd=0x7f22cc001598, rgi=0x7f22cc000a90) at /data/src/10.5/sql/slave.cc:4165 #14 0x000056068081d990 in exec_relay_log_event (thd=0x7f22cc001598, rli=0x56068406f6d8, serial_rgi=0x7f22cc000a90) at /data/src/10.5/sql/slave.cc:4482 #15 0x00005606808212fd in handle_slave_sql (arg=0x56068406da10) at /data/src/10.5/sql/slave.cc:5659 #16 0x0000560681002b56 in pfs_spawn_thread (arg=0x7f22e01face8) at /data/src/10.5/storage/perfschema/pfs.cc:2201 #17 0x00007f23150824a4 in start_thread (arg=0x7f230c312700) at pthread_create.c:456 #18 0x00007f23131b6d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 both variations are reproducible with InnoDB as well, with the same test cases. I don't know what happened when you tried, please double-check. it fails on 10.4 after completing MDEV-22747 because one of the commits you are backporting introduced the failure. This one: commit 0515577d128318e1b62511846d88d0c56226168d Author: Sergei Golubchik Date: Thu Mar 5 19:19:57 2020 +0100   cleanup: prepare "update_handler" for WITHOUT OVERLAPS

            People

              sachin.setiya.007 Sachin Setiya (Inactive)
              alice Alice Sherepa
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

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