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

Server crashes on import from MariaDB mysqldump export with partitioned Aria table

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 10.0.0, 5.5.28a
    • Fix Version/s: 10.0.3, 5.5.31
    • Component/s: None
    • Labels:
      None
    • Environment:
      Linux 64 bit and maybe Windows 32 bit

      Description

      The original description can be found at the end of this field. I've left it intact along with the summary for the reference of end users, as that's the symptoms they are likely to see.

      The following test case is a simplified extract from a dump file produced by mysqldump. It causes valgrind errors 'Invalid read' which, I suppose, is a root cause of the observed and described crash.

      --source include/have_partition.inc
       
      CREATE TABLE t1 (
        a SMALLINT NOT NULL DEFAULT '0',
        b CHAR(15) NOT NULL DEFAULT '',
        KEY (b)
      ) ENGINE=Aria
      PARTITION BY LIST (a) (
        PARTITION p1 VALUES IN (1),
        PARTITION p2 VALUES IN (2)
      );
      LOCK TABLES t1 WRITE;
      ALTER TABLE t1 DISABLE KEYS;

      ==4671== Thread 4:
      ==4671== Invalid read of size 8
      ==4671==    at 0x95B3B9: maria_status (ma_info.c:45)
      ==4671==    by 0x972830: ha_maria::info(unsigned int) (ha_maria.cc:2433)
      ==4671==    by 0x9710D1: ha_maria::disable_indexes(unsigned int) (ha_maria.cc:1873)
      ==4671==    by 0x7D75C4: handler::ha_disable_indexes(unsigned int) (handler.cc:3571)
      ==4671==    by 0xCAB2C6: ha_partition::disable_indexes(unsigned int) (ha_partition.cc:7532)
      ==4671==    by 0x7D75C4: handler::ha_disable_indexes(unsigned int) (handler.cc:3571)
      ==4671==    by 0x6B2398: mysql_alter_table(THD*, char*, char*, st_ha_create_information*, TABLE_LIST*, Alter_info*, unsigned int, st_order*, bool, bool) (sql_table.cc:6248)
      ==4671==    by 0x94CF2B: Alter_table_statement::execute(THD*) (sql_alter.cc:106)
      ==4671==    by 0x61791F: mysql_execute_command(THD*) (sql_parse.cc:4460)
      ==4671==    by 0x61AAC2: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5737)
      ==4671==    by 0x60E28F: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1055)
      ==4671==    by 0x60D546: do_command(THD*) (sql_parse.cc:794)
      ==4671==    by 0x715A44: do_handle_one_connection(THD*) (sql_connect.cc:1253)
      ==4671==    by 0x71542F: handle_one_connection (sql_connect.cc:1168)
      ==4671==    by 0xBB7C10: pfs_spawn_thread (pfs.cc:1015)
      ==4671==    by 0x5458EFB: start_thread (pthread_create.c:304)
      ==4671==  Address 0x118b38d0 is 16 bytes inside a block of size 128 free'd
      ==4671==    at 0x4C282E0: free (vg_replace_malloc.c:366)
      ==4671==    by 0xCDBA99: my_free (my_malloc.c:115)
      ==4671==    by 0x95DE6C: _ma_trnman_end_trans_hook (ma_state.c:532)
      ==4671==    by 0x977E14: trnman_end_trn (trnman.c:479)
      ==4671==    by 0x9ABF33: ma_commit (ma_commit.c:38)
      ==4671==    by 0x9738D2: ha_maria::implicit_commit(THD*, bool) (ha_maria.cc:2825)
      ==4671==    by 0x7D22F8: ha_commit_trans(THD*, bool) (handler.cc:1185)
      ==4671==    by 0x727EF0: trans_commit_implicit(THD*) (transaction.cc:224)
      ==4671==    by 0x610B16: mysql_execute_command(THD*) (sql_parse.cc:2114)
      ==4671==    by 0x61AAC2: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5737)
      ==4671==    by 0x60E28F: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1055)
      ==4671==    by 0x60D546: do_command(THD*) (sql_parse.cc:794)
      ==4671==    by 0x715A44: do_handle_one_connection(THD*) (sql_connect.cc:1253)
      ==4671==    by 0x71542F: handle_one_connection (sql_connect.cc:1168)
      ==4671==    by 0xBB7C10: pfs_spawn_thread (pfs.cc:1015)
      ==4671==    by 0x5458EFB: start_thread (pthread_create.c:304)

      revision-id: sergii@pisem.net-20121206163022-iyc7rupgh2oete89
      date: 2012-12-06 17:30:22 +0100
      revno: 3604
      branch: maria/5.5

      Also reproducible on current 10.0-base.
      Not reproducible with MyISAM instead of Aria.
      Could not reproduce on maria/5.3.

      ===========================
      Original description

      The problem doesn't affect the same table using MyISAM instead of Aria. The dump is created with default options of the mysqldump.exe included in MariaDB 5.5.28a Windows 32 bit version. The file created contains both the create statement and the insert statements, and the problem occours randomly after restoring about 100-200 MB of data. If I create two separate files for create table and inserts (I did it splitting the original dump file with "head" and "tail" commands), and I run the file separately, the problem doesn't occurs. Example:

      mysql mydb < dump.sql (crash)
      mysql mydb < create.sql; mysql mydb < data.sql (ok)
      cat create.sql data.sql | mysql mydb (crash)
      cat create.sql truncate.sql data.sql (ok)

      Inserting a truncate table statement between the create table and the inserts, the problem doesn't occours.
      Affected versions are 5.5.28a and 10.0.0 Linux 64 bit (under Ubuntu 12.04). On Windows Seven 32 bit, 5.5.28a, I get the problem the first time I tried, but not the second time. I attach the output of the server and the create table statement. If you need the data, it's a 100MB bzip2 file.

        Attachments

        1. create.sql
          6 kB
        2. mariadb_log.txt
          4 kB
        3. truncate.sql
          0.0 kB

          Activity

            People

            • Assignee:
              monty Michael Widenius
              Reporter:
              steris Risato Stefano
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: