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

Assertion `trid >= info->s->state.create_trid' failure or data corruption (key points to record outside datafile) on INSERT into an Aria table

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 5.5.30
    • 5.5.31
    • None

    Description

      Initially reported on the sales list. Quoting the complete text of the report from the mail, additional information follows the quote:

      System: Windows 32 and 64 bit (tested on XP/32, 2003/32 and 2008/64)
      Effected: MariaDB up to 5.5.30

      I have a specific (attached) Aria table with 2 columns, the fist being indexed as non-unique.

      CREATE TABLE `test` (
      `id` SMALLINT(5) UNSIGNED NOT NULL,
      `kundenid` SMALLINT(5) UNSIGNED NOT NULL,
      INDEX `id` (`id`)
      )
      ENGINE=Aria;

      In this table there are 42 records, 13 of them having id=4. When I add 2 more with id 4 and query all entries with id=4, it only shows me the 13 that already were in the database, but not the 2 newly added. They are only shown when I query all records.

      How to reproduce:
      1) Install a fresh copy of MariaDB (5.5.30)
      2) Copy attached my.ini in the appropriate folder and
      3) the test.* files in the test database.
      4) Run following queries:

      SELECT * FROM test;
      /* Affected rows: 0 Found rows: 42 Warnings: 0 Duration for 1 query: 0,000 sec. */

      SELECT * FROM test WHERE id=4;
      /* Affected rows: 0 Found rows: 13 Warnings: 0 Duration for 1 query: 0,000 sec. */

      INSERT INTO `test` (`id`, `kundenid`) VALUES (4, 12345);
      INSERT INTO `test` (`id`, `kundenid`) VALUES (4, 24587);
      /* Affected rows: 2 Found rows: 0 Warnings: 0 Duration for 2 queries: 0,016 sec. */

      SELECT * FROM test;
      /* Affected rows: 0 Found rows: 44 Warnings: 0 Duration for 1 query: 0,000 sec. */

      SELECT * FROM test WHERE id=4;
      /* Affected rows: 0 Found rows: 13 Warnings: 0 Duration for 1 query: 0,000 sec. */

      Only
      REPAIR TABLE `test`;
      recovers the missing records when selecting WHERE id=4:

      REPAIR TABLE `test`;
      /* Affected rows: 0 Found rows: 1 Warnings: 0 Duration for 1 query: 0,062 sec. */
      SELECT * FROM test WHERE id=4;
      /* Affected rows: 0 Found rows: 15 Warnings: 0 Duration for 1 query: 0,000 sec. */

      Additional information

      The issue is reproducible on Linux as well, even without the my.ini file. The problems start with the first INSERT. On a release build, it causes the table corruption, on the debug build it causes assertion failure.

      On a debug build:

      mysqld: 5.5/storage/maria/ma_key.c:103: transid_store_packed: Assertion `trid >= info->s->state.create_trid' failed.
      [ERROR] mysqld got signal 6 ;

      #7  0x00007fd94ec0a192 in __GI___assert_fail (assertion=0xe0fed8 "trid >= info->s->state.create_trid", file=0xe0fe90 "5.5/storage/maria/ma_key.c", line=103, function=0xe0fff0 "transid_store_packed") at assert.c:103
      #8  0x00000000009b3cf9 in transid_store_packed (info=0x7fd904013490, to=0x7fd904017bbb "\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245", trid=44) at 5.5/storage/maria/ma_key.c:103
      #9  0x00000000009b46a1 in _ma_make_key (info=0x7fd904013490, int_key=0x7fd9503cd8e0, keynr=0, key=0x7fd904017bb7 "", record=0x7fd904008e68 "\377\004", filepos=298, trid=44) at 5.5/storage/maria/ma_key.c:326
      #10 0x00000000009d62ba in maria_write (info=0x7fd904013490, record=0x7fd904008e68 "\377\004") at 5.5/storage/maria/ma_write.c:188
      #11 0x000000000095c805 in ha_maria::write_row (this=0x7fd90400c6d8, buf=0x7fd904008e68 "\377\004") at 5.5/storage/maria/ha_maria.cc:1265
      #12 0x00000000007d06c9 in handler::ha_write_row (this=0x7fd90400c6d8, buf=0x7fd904008e68 "\377\004") at 5.5/sql/handler.cc:5162
      #13 0x00000000005f57a7 in write_record (thd=0x3f60bd0, table=0x7fd90400bd10, info=0x7fd9503cdb50) at 5.5/sql/sql_insert.cc:1850
      #14 0x00000000005f33fc in mysql_insert (thd=0x3f60bd0, table_list=0x7fd904006628, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR, ignore=false) at 5.5/sql/sql_insert.cc:995
      #15 0x0000000000611d4e in mysql_execute_command (thd=0x3f60bd0) at 5.5/sql/sql_parse.cc:2935
      #16 0x0000000000619df6 in mysql_parse (thd=0x3f60bd0, rawbuf=0x7fd904006508 "INSERT INTO `test` (`id`, `kundenid`) VALUES (4, 12345)", length=55, parser_state=0x7fd9503ce550) at 5.5/sql/sql_parse.cc:5756
      #17 0x000000000060d598 in dispatch_command (command=COM_QUERY, thd=0x3f60bd0, packet=0x404fd11 "INSERT INTO `test` (`id`, `kundenid`) VALUES (4, 12345)", packet_length=55) at 5.5/sql/sql_parse.cc:1068
      #18 0x000000000060c7dd in do_command (thd=0x3f60bd0) at 5.5/sql/sql_parse.cc:794
      #19 0x0000000000710e36 in do_handle_one_connection (thd_arg=0x3f60bd0) at 5.5/sql/sql_connect.cc:1266
      #20 0x0000000000710821 in handle_one_connection (arg=0x3f60bd0) at 5.5/sql/sql_connect.cc:1181
      #21 0x00007fd94f9dae9a in start_thread (arg=0x7fd9503cf700) at pthread_create.c:308

      The stack trace from

      revision-id: sanja@askmonty.org-20130314170720-7qhmgzam5831ak30
      revno: 3699

      On a release build:

      MariaDB [test]> check table test extended;
      +-----------+-------+----------+----------+age done
      | Table     | Op    | Msg_type | Msg_text |
      +-----------+-------+----------+----------+
      | test.test | check | status   | OK       |
      +-----------+-------+----------+----------+
      1 row in set (0.12 sec)
       
      MariaDB [test]> show index in test;
      +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
      | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
      +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
      | test  |          1 | id       |            1 | id          | A         |           5 |     NULL | NULL   |      | BTREE      |         |               |
      +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
      1 row in set (0.00 sec)
       
      MariaDB [test]> select count(*) from test;
      +----------+
      | count(*) |
      +----------+
      |       42 |
      +----------+
      1 row in set (0.06 sec)
       
      MariaDB [test]> show table status like 'test';
      +------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-----------------+----------+-----------------+----------------------------------------+
      | Name | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time         | Update_time         | Check_time          | Collation       | Checksum | Create_options  | Comment                                |
      +------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-----------------+----------+-----------------+----------------------------------------+
      | test | Aria   |      10 | Page       |   42 |            390 |       16384 |     68719484928 |        16384 |         0 |           NULL | 2013-01-07 16:46:42 | 2013-03-18 01:38:11 | 2013-03-18 01:38:51 | utf8_general_ci |     NULL | page_checksum=1 | Loginrechte für die Nielsen-Statistik  |
      +------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-----------------+----------+-----------------+----------------------------------------+
      1 row in set (0.05 sec)
       
      MariaDB [test]> INSERT INTO `test` (`id`, `kundenid`) VALUES (4, 12345);
      Query OK, 1 row affected (0.05 sec)
       
      MariaDB [test]> check table test extended;
      +-----------+-------+----------+---------------------------------------------------------------+
      | Table     | Op    | Msg_type | Msg_text                                                      |
      +-----------+-------+----------+---------------------------------------------------------------+
      | test.test | check | error    | Found key at page 8192 that points to record outside datafile |
      | test.test | check | error    | Corrupt                                                       |
      +-----------+-------+----------+---------------------------------------------------------------+
      2 rows in set (0.05 sec)

      However, I couldn't reproduce the problem by dumping the table and restoring the dump. I could try more if I get any hint on what can possibly cause this. Meanwhile I asked the reporter by email for more information on how they got the table in this state, haven't got a response yet.

      Attachments

        Activity

          The issue was that the table had a marker 'transaction id of creation time' that was bigger than the current transaction id for the server.
          This could happen if:

          • You copied the table from one server to another
          • You removed the aria_control_file

          Normally MariaDB should have noticed that the file was copied and done an automatic zerofill on the table. The test to detect this didn't however work in the case where the table was just repaired before copied.

          I have now fixed this and will push this in to the 5.5 tree.
          I did the additional fixes:

          • Added a check to detect a wrong create_trid in 'check table'.
          • aria_chk -dvv will now write out also the create_trid (to make future error finding easier)
          • aria_chk --zerofill doesn't anymore require a aria_control_file
          • Removed some warnings from safemalloc when using aria_chk.

          Until you have the next release, you should do a 'aria_chk --zerofill' on the table before you install it on another server than the original one.

          monty Michael Widenius added a comment - The issue was that the table had a marker 'transaction id of creation time' that was bigger than the current transaction id for the server. This could happen if: You copied the table from one server to another You removed the aria_control_file Normally MariaDB should have noticed that the file was copied and done an automatic zerofill on the table. The test to detect this didn't however work in the case where the table was just repaired before copied. I have now fixed this and will push this in to the 5.5 tree. I did the additional fixes: Added a check to detect a wrong create_trid in 'check table'. aria_chk -dvv will now write out also the create_trid (to make future error finding easier) aria_chk --zerofill doesn't anymore require a aria_control_file Removed some warnings from safemalloc when using aria_chk. Until you have the next release, you should do a 'aria_chk --zerofill' on the table before you install it on another server than the original one.

          Fix pushed into 5.5

          monty Michael Widenius added a comment - Fix pushed into 5.5

          People

            monty Michael Widenius
            elenst Elena Stepanova
            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.