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

Assertion `memcmp(field, field_ref_zero, 7)' failed in trx_undo_page_report_modify upon optimizing table under innodb_optimize_fulltext_only

Details

    Description

      --source include/have_innodb.inc
      		 
       
      		 
      CREATE TABLE t1 (f1 TEXT, f2 TEXT, FULLTEXT KEY (f2)) ENGINE=InnoDB DEFAULT CHARSET UTF8;
      		 
      INSERT INTO t1 (f1) VALUES ('foo'),('bar');
      		 
      DELETE FROM t1 LIMIT 1;
      		 
      ALTER TABLE t1 ADD FULLTEXT KEY (f1);
      		 
      SET @optimize_fulltext.save= @@innodb_optimize_fulltext_only;
      		 
      SET GLOBAL innodb_optimize_fulltext_only= 1;
      		 
      OPTIMIZE TABLE t1;
      		 
       
      		 
      # Cleanup
      		 
      DROP TABLE t1;
      		 
      SET GLOBAL innodb_optimize_fulltext_only= @optimize_fulltext.save;

      10.2 5ec9b88e111

      		 
      mysqld: /data/src/10.2/storage/innobase/trx/trx0rec.cc:956: ulint trx_undo_page_report_modify(ib_page_t*, trx_t*, dict_index_t*, const rec_t*, const ulint*, const upd_t*, ulint, const dtuple_t*, mtr_t*): Assertion `memcmp(field, field_ref_zero, 7)' failed.
      		 
      181207  1:12:38 [ERROR] mysqld got signal 6 ;
      		 
       
      		 
      #7  0x00007f2d2253cee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
      		 
      #8  0x0000564dca4c8fcc in trx_undo_page_report_modify (undo_page=0x7f2d17e00000 "", trx=0x7f2d1c4af278, index=0x7f2cc8059558, rec=0x7f2d17da8080 "bar", offsets=0x7f2d1c20f8a0, update=0x0, cmpl_info=0, row=0x7f2cc8133458, mtr=0x7f2d1c20eda0) at /data/src/10.2/storage/innobase/trx/trx0rec.cc:956
      		 
      #9  0x0000564dca4cc321 in trx_undo_report_row_operation (thr=0x7f2cc80afc78, index=0x7f2cc8059558, clust_entry=0x7f2cc8133458, update=0x0, cmpl_info=0, rec=0x7f2d17da8080 "bar", offsets=0x7f2d1c20f8a0, roll_ptr=0x7f2d1c20f338) at /data/src/10.2/storage/innobase/trx/trx0rec.cc:2103
      		 
      #10 0x0000564dca52406a in btr_cur_del_mark_set_clust_rec (block=0x7f2d177df690, rec=0x7f2d17da8080 "bar", index=0x7f2cc8059558, offsets=0x7f2d1c20f8a0, thr=0x7f2cc80afc78, entry=0x7f2cc8133458, mtr=0x7f2d1c20fbc0) at /data/src/10.2/storage/innobase/btr/btr0cur.cc:4832
      		 
      #11 0x0000564dca47b37e in row_upd_del_mark_clust_rec (node=0x7f2cc80af408, index=0x7f2cc8059558, offsets=0x7f2d1c20f8a0, thr=0x7f2cc80afc78, referenced=0, foreign=false, mtr=0x7f2d1c20fbc0) at /data/src/10.2/storage/innobase/row/row0upd.cc:2984
      		 
      #12 0x0000564dca47bc1f in row_upd_clust_step (node=0x7f2cc80af408, thr=0x7f2cc80afc78) at /data/src/10.2/storage/innobase/row/row0upd.cc:3158
      		 
      #13 0x0000564dca47c100 in row_upd (node=0x7f2cc80af408, thr=0x7f2cc80afc78) at /data/src/10.2/storage/innobase/row/row0upd.cc:3279
      		 
      #14 0x0000564dca47c5d9 in row_upd_step (thr=0x7f2cc80afc78) at /data/src/10.2/storage/innobase/row/row0upd.cc:3425
      		 
      #15 0x0000564dca3d16b8 in que_thr_step (thr=0x7f2cc80afc78) at /data/src/10.2/storage/innobase/que/que0que.cc:1027
      		 
      #16 0x0000564dca3d1993 in que_run_threads_low (thr=0x7f2cc80afc78) at /data/src/10.2/storage/innobase/que/que0que.cc:1107
      		 
      #17 0x0000564dca3d1b3c in que_run_threads (thr=0x7f2cc80afc78) at /data/src/10.2/storage/innobase/que/que0que.cc:1147
      		 
      #18 0x0000564dca62fcb1 in fts_eval_sql (trx=0x7f2d1c4af278, graph=0x7f2cc80afba0) at /data/src/10.2/storage/innobase/fts/fts0sql.cc:240
      		 
      #19 0x0000564dca621cea in fts_optimize_write_word (trx=0x7f2d1c4af278, fts_table=0x7f2cc805fd00, word=0x7f2cc8041158, nodes=0x7f2cc8063228) at /data/src/10.2/storage/innobase/fts/fts0opt.cc:1471
      		 
      #20 0x0000564dca622152 in fts_optimize_compact (optim=0x7f2cc805fce8, index=0x7f2cc8055358, start_time=1544137958) at /data/src/10.2/storage/innobase/fts/fts0opt.cc:1561
      		 
      #21 0x0000564dca62277a in fts_optimize_words (optim=0x7f2cc805fce8, index=0x7f2cc8055358, word=0x7f2d1c2109b0) at /data/src/10.2/storage/innobase/fts/fts0opt.cc:1815
      		 
      #22 0x0000564dca622f16 in fts_optimize_index (optim=0x7f2cc805fce8, index=0x7f2cc8055358) at /data/src/10.2/storage/innobase/fts/fts0opt.cc:2000
      		 
      #23 0x0000564dca623868 in fts_optimize_indexes (optim=0x7f2cc805fce8) at /data/src/10.2/storage/innobase/fts/fts0opt.cc:2304
      		 
      #24 0x0000564dca623bd1 in fts_optimize_table (table=0x7f2cc809a918) at /data/src/10.2/storage/innobase/fts/fts0opt.cc:2477
      		 
      #25 0x0000564dca2f37a8 in ha_innobase::optimize (this=0x7f2cc8046fc8, thd=0x7f2cc8000b00, check_opt=0x7f2cc80055f0) at /data/src/10.2/storage/innobase/handler/ha_innodb.cc:14630
      		 
      #26 0x0000564dc9fd84d1 in handler::ha_optimize (this=0x7f2cc8046fc8, thd=0x7f2cc8000b00, check_opt=0x7f2cc80055f0) at /data/src/10.2/sql/handler.cc:4115
      		 
      #27 0x0000564dc9eb401f in mysql_admin_table(THD *, TABLE_LIST *, HA_CHECK_OPT *, const char *, thr_lock_type, bool, bool, uint, int (*)(THD *, TABLE_LIST *, HA_CHECK_OPT *), struct {...}, int (*)(THD *, TABLE_LIST *, HA_CHECK_OPT *)) (thd=0x7f2cc8000b00, tables=0x7f2cc8012518, check_opt=0x7f2cc80055f0, operator_name=0x564dca82dfc8 "optimize", lock_type=TL_WRITE, org_open_for_modify=true, repair_table_use_frm=false, extra_open_options=0, prepare_func=0x0, operator_func=(int (handler::*)(handler * const, THD *, HA_CHECK_OPT *)) 0x564dc9fd8450 <handler::ha_optimize(THD*, st_ha_check_opt*)>, view_operator_func=0x0) at /data/src/10.2/sql/sql_admin.cc:798
      		 
      #28 0x0000564dc9eb63bc in Sql_cmd_optimize_table::execute (this=0x7f2cc8012b30, thd=0x7f2cc8000b00) at /data/src/10.2/sql/sql_admin.cc:1370
      		 
      #29 0x0000564dc9d5e35b in mysql_execute_command (thd=0x7f2cc8000b00) at /data/src/10.2/sql/sql_parse.cc:6226
      		 
      #30 0x0000564dc9d631bd in mysql_parse (thd=0x7f2cc8000b00, rawbuf=0x7f2cc8012448 "OPTIMIZE TABLE t1", length=17, parser_state=0x7f2d1c212200, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:8013
      		 
      #31 0x0000564dc9d50af5 in dispatch_command (command=COM_QUERY, thd=0x7f2cc8000b00, packet=0x7f2cc80960c1 "", packet_length=17, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1824
      		 
      #32 0x0000564dc9d4f458 in do_command (thd=0x7f2cc8000b00) at /data/src/10.2/sql/sql_parse.cc:1378
      		 
      #33 0x0000564dc9ea1bc9 in do_handle_one_connection (connect=0x564dcde4ee00) at /data/src/10.2/sql/sql_connect.cc:1335
      		 
      #34 0x0000564dc9ea1956 in handle_one_connection (arg=0x564dcde4ee00) at /data/src/10.2/sql/sql_connect.cc:1241
      		 
      #35 0x0000564dca2c75ee in pfs_spawn_thread (arg=0x564dcdd9a2b0) at /data/src/10.2/storage/perfschema/pfs.cc:1862
      		 
      #36 0x00007f2d23ff8494 in start_thread (arg=0x7f2d1c213700) at pthread_create.c:333
      		 
      #37 0x00007f2d225f993f in clone () from /lib/x86_64-linux-gnu/libc.so.6

      Not reproducible on 10.1.

      Attachments

        Activity

          marko Marko Mäkelä added a comment -

          I repeated this both on 10.4 and 10.2. The assertion during an internal DELETE operation notices that DB_ROLL_PTR is 0 in a record of the clustered index of a hidden table FTS_0000000000000013_0000000000000023_INDEX_2. The value DB_ROLL_PTR=0 is never valid, because neither the undo page number nor the byte offset can be 0. A valid ‘dummy’ value would be 1UL<<55, to signify that the record was freshly inserted. This dummy value is being used in MDEV-12288, together with DB_TRX_ID=0.

          The bogus value is being initialized in row_fts_merge_insert():

          	roll_ptr_t		roll_ptr = 0;
          		 
          …
          		 
          	/* Set TRX_ID and ROLL_PTR */
          		 
          	trx_write_trx_id(trx_id_buf, trx->id);
          		 
          	field = dtuple_get_nth_field(ins_ctx.tuple, 2);
          		 
          	dfield_set_data(field, &trx_id_buf, 6);
          		 
           
          		 
          	field = dtuple_get_nth_field(ins_ctx.tuple, 3);
          		 
          	dfield_set_data(field, &roll_ptr, 7);

          In 10.3 with MDEV-12288, we should be using the special value reset_trx_id for these fields. In 10.2, it is probably safer to use the non-zero DB_TRX_ID.

          It seems to me that this error was introduced in MySQL 5.7.5. MySQL is lacking the debug assertion that is failing in MariaDB. It was added by me in a related bug fix of MDEV-14407 Assertion failure during rollback, with the following commit message:

          Rollback attempted to dereference DB_ROLL_PTR=0, which cannot possibly be a valid undo log pointer. A safe canonical value would be roll_ptr_t(1) << ROLL_PTR_INSERT_FLAG_POS which is what was chosen in MDEV-12288.

          It is uncertain whether this bug could have any other impact than a minor performance impact in 10.3 and later. If a transaction and a read view was created concurrently with the ALTER TABLE operation such that not all the fts_parallel_merge() threads had been created yet, then this read view might have access to the fulltext indexes and might be able to try to dereference the bogus DB_ROLL_PTR=0 to fetch non-existent old history of the records.

          marko Marko Mäkelä added a comment - I repeated this both on 10.4 and 10.2. The assertion during an internal DELETE operation notices that DB_ROLL_PTR is 0 in a record of the clustered index of a hidden table FTS_0000000000000013_0000000000000023_INDEX_2 . The value DB_ROLL_PTR=0 is never valid, because neither the undo page number nor the byte offset can be 0. A valid ‘dummy’ value would be 1UL<<55 , to signify that the record was freshly inserted. This dummy value is being used in MDEV-12288 , together with DB_TRX_ID=0 . The bogus value is being initialized in row_fts_merge_insert() : roll_ptr_t roll_ptr = 0; … /* Set TRX_ID and ROLL_PTR */ trx_write_trx_id(trx_id_buf, trx->id); field = dtuple_get_nth_field(ins_ctx.tuple, 2); dfield_set_data(field, &trx_id_buf, 6);   field = dtuple_get_nth_field(ins_ctx.tuple, 3); dfield_set_data(field, &roll_ptr, 7); In 10.3 with MDEV-12288 , we should be using the special value reset_trx_id for these fields. In 10.2, it is probably safer to use the non-zero DB_TRX_ID . It seems to me that this error was introduced in MySQL 5.7.5 . MySQL is lacking the debug assertion that is failing in MariaDB. It was added by me in a related bug fix of MDEV-14407 Assertion failure during rollback, with the following commit message: Rollback attempted to dereference DB_ROLL_PTR=0, which cannot possibly be a valid undo log pointer. A safe canonical value would be roll_ptr_t(1) << ROLL_PTR_INSERT_FLAG_POS which is what was chosen in MDEV-12288 . It is uncertain whether this bug could have any other impact than a minor performance impact in 10.3 and later. If a transaction and a read view was created concurrently with the ALTER TABLE operation such that not all the fts_parallel_merge() threads had been created yet, then this read view might have access to the fulltext indexes and might be able to try to dereference the bogus DB_ROLL_PTR=0 to fetch non-existent old history of the records.

          People

            marko Marko Mäkelä
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            2 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.