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

BLOB corruption on UPDATE of PRIMARY KEY with FOREIGN KEY

Details

    Description

      origin/10.6 8171f9da87c9e062b056834942634f04f39d5aea 2023-06-09T10:22:34+10:00
      		 
      mysqld: /data/Server/10.6K/storage/innobase/row/row0upd.cc:2132: bool row_upd_clust_rec_by_insert_inherit_func(const rec_t*, dict_index_t*, const rec_offs*, dtuple_t*, const upd_t*): Assertion `!(rec_data[12U] & 128U)' failed.
      		 
      ...
      		 
      (rr) bt
      		 
      #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
      		 
      #1  0x000078866d959859 in __GI_abort () at abort.c:79
      		 
      #2  0x000078866d959729 in __assert_fail_base (fmt=0x78866daef588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55bc4a7879a5 "!(rec_data[12U] & 128U)", 
          file=0x55bc4a787b78 "/data/Server/10.6K/storage/innobase/row/row0upd.cc", line=2132, function=<optimized out>) at assert.c:92
      		 
      #3  0x000078866d96af36 in __GI___assert_fail (assertion=assertion@entry=0x55bc4a7879a5 "!(rec_data[12U] & 128U)", file=file@entry=0x55bc4a787b78 "/data/Server/10.6K/storage/innobase/row/row0upd.cc", line=line@entry=2132, 
          function=function@entry=0x55bc4a787dc8 "bool row_upd_clust_rec_by_insert_inherit_func(const rec_t*, dict_index_t*, const rec_offs*, dtuple_t*, const upd_t*)") at assert.c:101
      		 
      #4  0x000055bc4a0f7f2a in row_upd_clust_rec_by_insert_inherit_func (rec=rec@entry=0xca11b4c0da "\200", index=index@entry=0x630d14020d10, offsets=offsets@entry=0x7fa148ee5db0, entry=entry@entry=0x3ef2c063640, 
          update=0x630d14025730) at /data/Server/10.6K/storage/innobase/row/row0upd.cc:2132
      		 
      #5  0x000055bc4a100576 in row_upd_clust_rec_by_insert (node=node@entry=0x630d14025530, index=index@entry=0x630d14020d10, thr=thr@entry=0x3ef2c04eba0, referenced=referenced@entry=true, foreign=foreign@entry=false, 
          mtr=mtr@entry=0x7fa148ee6300) at /data/Server/10.6K/storage/innobase/row/row0upd.cc:2263
      		 
      #6  0x000055bc4a102a43 in row_upd_clust_step (node=node@entry=0x630d14025530, thr=thr@entry=0x3ef2c04eba0) at /data/Server/10.6K/storage/innobase/row/row0upd.cc:2682
      		 
      #7  0x000055bc4a102d95 in row_upd (node=node@entry=0x630d14025530, thr=thr@entry=0x3ef2c04eba0) at /data/Server/10.6K/storage/innobase/row/row0upd.cc:2758
      		 
      #8  0x000055bc4a103440 in row_upd_step (thr=thr@entry=0x3ef2c04eba0) at /data/Server/10.6K/storage/innobase/row/row0upd.cc:2900
      		 
      #9  0x000055bc4a0a3987 in row_update_for_mysql (prebuilt=0x630d14024b20) at /data/Server/10.6K/storage/innobase/row/row0mysql.cc:1691
      		 
      #10 0x000055bc49f14b5b in ha_innobase::update_row (this=0x630d1402cf40, old_row=0x630d14027518 "\376\v\001", new_row=0x630d14027508 "\376", <incomplete sequence \304>)
      		 
          at /data/Server/10.6K/storage/innobase/handler/ha_innodb.cc:8691
      		 
      #11 0x000055bc49ba740d in handler::ha_update_row (this=0x630d1402cf40, old_data=0x630d14027518 "\376\v\001", new_data=0x630d14027508 "\376", <incomplete sequence \304>) at /data/Server/10.6K/sql/handler.cc:7684
      		 
      #12 0x000055bc499b14bc in mysql_update (thd=thd@entry=0x3ef2c002788, table_list=<optimized out>, fields=..., values=..., conds=<optimized out>, order_num=<optimized out>, order=<optimized out>, limit=18446744073709551615, 
          ignore=<optimized out>, found_return=<optimized out>, updated_return=<optimized out>) at /data/Server/10.6K/sql/sql_update.cc:1087
      		 
      #13 0x000055bc498aa9c0 in mysql_execute_command (thd=thd@entry=0x3ef2c002788, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /data/Server/10.6K/sql/sql_limit.h:94
      		 
      #14 0x000055bc49894a47 in mysql_parse (thd=thd@entry=0x3ef2c002788, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x7fa148ee7370) at /data/Server/10.6K/sql/sql_parse.cc:8036
      		 
      #15 0x000055bc498a4204 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x3ef2c002788, packet=packet@entry=0x3ef2c00c489 "UPDATE test.t_p SET col1 = 196 /* E_R Thread2 QNO 57 CON_ID 17 */ ", 
          packet_length=packet_length@entry=66, blocking=blocking@entry=true) at /data/Server/10.6K/sql/sql_class.h:1388
      		 
      #16 0x000055bc498a762c in do_command (thd=0x3ef2c002788, blocking=blocking@entry=true) at /data/Server/10.6K/sql/sql_parse.cc:1409
      		 
      #17 0x000055bc49a0e122 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55bc4c842b68, put_in_cache=put_in_cache@entry=true) at /data/Server/10.6K/sql/sql_connect.cc:1416
      		 
      #18 0x000055bc49a0e603 in handle_one_connection (arg=0x55bc4c842b68) at /data/Server/10.6K/sql/sql_connect.cc:1318
      		 
      #19 0x000078866db2f609 in start_thread (arg=<optimized out>) at pthread_create.c:477
      		 
      #20 0x000078866da56293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
      		 
      (rr)
      		 
      pluto:/data/results/1686309626/TBR-1808$ _RR_TRACE_DIR=./1/rr/ rr replay --mark-stdio
      		 
       
      		 
      RQG
      		 
      ====
      		 
      # git clone https://github.com/mleich1/rqg --branch <pick the right branch> RQG
      		 
      #
      		 
      # GIT_SHOW: HEAD -> master, origin/master, origin/HEAD ad3888c646e0b35ae2e4aa3fa4a568e25dbd92fd 2023-06-08T21:26:08+02:00
      		 
      # rqg.pl  : Version 4.2.1 (2022-12)
      		 
      #
      		 
      # $RQG_HOME/rqg.pl \
      		 
      # --duration=300 \
      		 
      # --queries=10000000 \
      		 
      # --no_mask \
      		 
      # --seed=random \
      		 
      # --gendata_sql=conf/mariadb/table_stress.sql \
      		 
      # --rpl_mode=none \
      		 
      # --max_gd_duration=1200 \
      		 
      # --engine=InnoDB \
      		 
      # --gendata=conf/mariadb/table_stress.zz \
      		 
      # --mysqld=--net_write_timeout=60 \
      		 
      # --mysqld=--sync-binlog=1 \
      		 
      # --mysqld=--loose-idle_readonly_transaction_timeout=0 \
      		 
      # --mysqld=--loose-table_lock_wait_timeout=50 \
      		 
      # --mysqld=--innodb-lock-wait-timeout=50 \
      		 
      # --mysqld=--innodb-buffer-pool-size=256M \
      		 
      # --mysqld=--innodb_page_size=16K \
      		 
      # --mysqld=--loose-idle_transaction_timeout=0 \
      		 
      # --mysqld=--connect_timeout=60 \
      		 
      # --mysqld=--loose_innodb_change_buffering=none \
      		 
      # --mysqld=--loose-innodb_fatal_semaphore_wait_threshold=300 \
      		 
      # --mysqld=--log_bin_trust_function_creators=1 \
      		 
      # --mysqld=--interactive_timeout=28800 \
      		 
      # --mysqld=--log-output=none \
      		 
      # --mysqld=--file-key-management-filename=$RQG_HOME/conf/mariadb/encryption_keys.txt \
      		 
      # --mysqld=--loose-max-statement-time=30 \
      		 
      # --mysqld=--loose-plugin-load-add=provider_lz4.so \
      		 
      # --mysqld=--loose-debug_assert_on_not_freed_memory=0 \
      		 
      # --mysqld=--net_read_timeout=30 \
      		 
      # --mysqld=--loose-innodb_evict_tables_on_commit_debug=on \
      		 
      # --mysqld=--lock-wait-timeout=86400 \
      		 
      # --mysqld=--log-bin \
      		 
      # --mysqld=--loose-innodb_read_only_compressed=OFF \
      		 
      # --mysqld=--loose_innodb_lock_schedule_algorithm=fcfs \
      		 
      # --mysqld=--slave_net_timeout=60 \
      		 
      # --mysqld=--loose-innodb-sync-debug \
      		 
      # --mysqld=--loose-idle_write_transaction_timeout=0 \
      		 
      # --mysqld=--plugin-load-add=file_key_management.so \
      		 
      # --mysqld=--loose-innodb_compression_level=1 \
      		 
      # --mysqld=--wait_timeout=28800 \
      		 
      # --mysqld=--innodb_undo_log_truncate=OFF \
      		 
      # --reporters=Backtrace,Deadlock,None \
      		 
      # --validators=None \
      		 
      # --grammar=TBR-1808.yy \
      		 
      # --threads=2 \
      		 
      # <local settings>
      		 
       
      		 
      The same test showed on various development trees MDEV-30869 instead.
      		 
       
      		 
      rqg grammar
      		 
      create_child:
      		 
          CREATE TABLE birth . child LIKE birth . parent ; ALTER TABLE birth . child ADD FOREIGN KEY (col1) REFERENCES birth . parent(col1) ;
      		 
      create_parent:
      		 
          CREATE TABLE birth . parent ( col1 INT PRIMARY KEY, col_text TEXT ) ;
      		 
      move_to_test:
      		 
          RENAME TABLE birth . parent TO test . t_p , birth . child TO test . t_c ;
      		 
       
      		 
      my_int:
      		 
          { $my_int= 1 } |
      		 
          { $my_int= $prng->int( 65, 512) } ;
      		 
       
      		 
      thread1:
      		 
          UPDATE test . t_p SET col1 = 1 |
      		 
          UPDATE test . t_c SET col1 = 1 ;
      		 
       
      		 
      thread1_connect:
      		 
          ;
      		 
       
      		 
      thread1_init:
      		 
          CREATE SCHEMA birth ; create_parent ; create_child ; move_to_test ;
      		 
       
      		 
      thread2:
      		 
          DELETE FROM test . t_p WHERE col1 = my_int OR col1 IS NULL |
      		 
          DELETE FROM test . t_c WHERE col1 = my_int OR col1 IS NULL |
      		 
          UPDATE test . t_p SET col1 = { $my_int= $prng->int( 65, 512) } |
      		 
          UPDATE test . t_p SET col1 = { $my_int= $prng->int( 65, 512) } |
      		 
          INSERT INTO test . t_p (col1, col_text) VALUES ( 1 , REPEAT('A', @fill_amount) ) |
      		 
          INSERT INTO test . t_c (col1, col_text) VALUES ( 1 , REPEAT('A', @fill_amount) ) ;
      		 
       
      		 
      thread2_connect:
      		 
          SET AUTOCOMMIT = 1; SET @fill_amount = (@@innodb_page_size / 2 ) + 1 ;
      		 
       
      		 
      thread2_init:
      		 
          ;

      Attachments

        Issue Links

          duplicates

          Bug - A problem which impairs or prevents the functions of the product. MDEV-30869 Failing assertion: rec == NULL || !(data[BTR_EXTERN_LEN] & BTR_EXTERN_OWNER_FLAG)

          • Major - Major loss of function.
          • Open
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-32174 ROW_FORMAT=COMPRESSED table corruption due to ROLLBACK

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

          Activity

            Ascending order - Click to sort in descending order
            View 5 older comments
            marko Marko Mäkelä added a comment -

            It looks like the PRIMARY KEY(col1) is being updated back and forth quite a bit. The flag is set during the execution of the following statement, which seems to match exactly one row.

            UPDATE test.t_p SET col1 = 12 /* E_R Thread1 QNO 12 CON_ID 12 */;

            It is writing 2 undo log records, one for inserting the updated row and another for delete-marking the old row. After this, we get the assertion failure when executing a statement in another connection:

            UPDATE test.t_p SET col1 = 1 /* E_R Thread2 QNO 27 CON_ID 13 */;

            At the time of the first UPDATE, there is exactly one record in the table, with col1=1.

            There must be some reason why this is not repeatable by running the following test:

            --source include/have_innodb.inc
            		 
            CREATE TABLE t_p (col1 INT PRIMARY KEY, col_text TEXT) ENGINE=InnoDB;
            		 
            INSERT INTO t_p VALUES (1, REPEAT('A', @@innodb_page_size / 2));
            		 
            UPDATE t_p SET col1=12;
            		 
            UPDATE t_p SET col1=1;
            		 
            DROP TABLE t_p;

            marko Marko Mäkelä added a comment - It looks like the PRIMARY KEY(col1) is being updated back and forth quite a bit. The flag is set during the execution of the following statement, which seems to match exactly one row. UPDATE test.t_p SET col1 = 12 /* E_R Thread1 QNO 12 CON_ID 12 */ ; It is writing 2 undo log records, one for inserting the updated row and another for delete-marking the old row. After this, we get the assertion failure when executing a statement in another connection: UPDATE test.t_p SET col1 = 1 /* E_R Thread2 QNO 27 CON_ID 13 */ ; At the time of the first UPDATE , there is exactly one record in the table, with col1=1 . There must be some reason why this is not repeatable by running the following test: --source include/have_innodb.inc CREATE TABLE t_p (col1 INT PRIMARY KEY , col_text TEXT) ENGINE=InnoDB; INSERT INTO t_p VALUES (1, REPEAT( 'A' , @@innodb_page_size / 2)); UPDATE t_p SET col1=12; UPDATE t_p SET col1=1; DROP TABLE t_p;
            marko Marko Mäkelä added a comment -

            I can reproduce the failure with the following test case:

            --source include/have_innodb.inc
            		 
            CREATE TABLE t1 (pk INT PRIMARY KEY, t TEXT) ENGINE=InnoDB;
            		 
            CREATE TABLE t2 (pk INT PRIMARY KEY, FOREIGN KEY (pk) REFERENCES t1(pk))
            		 
            ENGINE=InnoDB;
            		 
             
            		 
            INSERT INTO t1 SET pk=1, t=REPEAT('A', @@innodb_page_size / 2);
            		 
            INSERT INTO t2 SET pk=1;
            		 
            --connect (con1,localhost,root,,test)
            		 
            BEGIN;
            		 
            DELETE FROM t2;
            		 
            --connection default
            		 
            --send
            		 
            UPDATE t1 SET pk=12;
            		 
            --connection con1
            		 
            let $wait_condition=
            		 
            SELECT count(*) > 0 FROM INFORMATION_SCHEMA.PROCESSLIST WHERE state='Updating';
            		 
            --source include/wait_condition.inc
            		 
            COMMIT;
            		 
            --connection default
            		 
            --reap
            		 
            UPDATE t1 SET pk=1;
            		 
            DROP TABLE t2, t1;

            10.6 2f467de4c4851d2f9b0f3bec54f748d92349582a

            		 
            mariadbd: /mariadb/10.6/storage/innobase/row/row0upd.cc:2130: bool row_upd_clust_rec_by_insert_inherit_func(const rec_t*, dict_index_t*, const rec_offs*, dtuple_t*, const upd_t*): Assertion `!(rec_data[12U] & 128U)' failed.

            The issue is that the first UPDATE will copy the ‘disowned’ flag from the original record’s BLOB, so neither of the 2 records in the parent table (the delete-marked 1, or the normal 12) will ‘own’ the BLOB.

            marko Marko Mäkelä added a comment - I can reproduce the failure with the following test case: --source include/have_innodb.inc CREATE TABLE t1 (pk INT PRIMARY KEY , t TEXT) ENGINE=InnoDB; CREATE TABLE t2 (pk INT PRIMARY KEY , FOREIGN KEY (pk) REFERENCES t1(pk)) ENGINE=InnoDB;   INSERT INTO t1 SET pk=1, t=REPEAT( 'A' , @@innodb_page_size / 2); INSERT INTO t2 SET pk=1; --connect (con1,localhost,root,,test) BEGIN ; DELETE FROM t2; --connection default --send UPDATE t1 SET pk=12; --connection con1 let $wait_condition= SELECT count (*) > 0 FROM INFORMATION_SCHEMA.PROCESSLIST WHERE state= 'Updating' ; --source include/wait_condition.inc COMMIT ; --connection default --reap UPDATE t1 SET pk=1; DROP TABLE t2, t1; 10.6 2f467de4c4851d2f9b0f3bec54f748d92349582a mariadbd: /mariadb/10.6/storage/innobase/row/row0upd.cc:2130: bool row_upd_clust_rec_by_insert_inherit_func(const rec_t*, dict_index_t*, const rec_offs*, dtuple_t*, const upd_t*): Assertion `!(rec_data[12U] & 128U)' failed. The issue is that the first UPDATE will copy the ‘disowned’ flag from the original record’s BLOB, so neither of the 2 records in the parent table (the delete-marked 1, or the normal 12) will ‘own’ the BLOB.
            marko Marko Mäkelä added a comment -

            mleich, please test the patch on both 10.4 and 10.6.

            marko Marko Mäkelä added a comment - mleich , please test the patch on both 10.4 and 10.6.
            mleich Matthias Leich added a comment - 

            The trees
            		 
            - origin/10.4-MDEV-31441 89bc52f131440c93e79c32c04f1239ec6063ca03 2023-11-27T10:05:39+02:00
            		 
            - origin/10.6 2f467de4c4851d2f9b0f3bec54f748d92349582a 2023-11-24T14:25:32+02:00
            		 
              + cherry pick of MDEV-31441 patch
            		 
            performed well in RQG testing.

            mleich Matthias Leich added a comment - The trees - origin/10.4-MDEV-31441 89bc52f131440c93e79c32c04f1239ec6063ca03 2023-11-27T10:05:39+02:00 - origin/10.6 2f467de4c4851d2f9b0f3bec54f748d92349582a 2023-11-24T14:25:32+02:00 + cherry pick of MDEV-31441 patch performed well in RQG testing.
            vlad.lesin Vladislav Lesin added a comment -

            Looks good to me.

            vlad.lesin Vladislav Lesin added a comment - Looks good to me.

            People

              marko Marko Mäkelä
              mleich Matthias Leich
              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.