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

Server crash or assertion `item->type() == Item::STRING_ITEM' failure on LOAD DATA through a view with statement binary logging

Details

    Description

      The following test case

      --source include/have_binlog_format_statement.inc
       
      --write_file $MYSQLTEST_VARDIR/l.data 
      1
      EOF
       
      CREATE TABLE t1 (i INT);
      CREATE VIEW v1 AS SELECT i FROM t1;
      --eval LOAD DATA LOCAL INFILE '$MYSQLTEST_VARDIR/l.data' INTO TABLE v1 (i)

      causes an assertion failure with debug build or a crash with release build.

      sql/sql_load.cc:745: bool write_execute_load_query_log_event(THD*, sql_exchange*, const char*, const char*, bool, enum_duplicates, bool, bool, int): Assertion `item->type() == Item::STRING_ITEM' failed.
      141110  0:41:00 [ERROR] mysqld got signal 6 ;

      #6  0x00007f47301e36f1 in *__GI___assert_fail (assertion=0xe37cf0 "item->type() == Item::STRING_ITEM", file=<optimized out>, line=745, function=0xe38720 "bool write_execute_load_query_log_event(THD*, sql_exchange*, const char*, const char*, bool, enum_duplicates, bool, bool, int)") at assert.c:81
      #7  0x000000000093253a in write_execute_load_query_log_event (thd=0x7f472fb4b060, ex=0x7f472ae871c8, db_arg=0x7f472ae87818 "test", table_name_arg=0x7f472ae87218 "v1", is_concurrent=false, duplicates=DUP_ERROR, ignore=true, transactional_table=false, errcode=0) at 5.5/sql/sql_load.cc:745
      #8  0x00000000009320cb in mysql_load (thd=0x7f472fb4b060, ex=0x7f472ae871c8, table_list=0x7f472ae87250, fields_vars=..., set_fields=..., set_values=..., handle_duplicates=DUP_ERROR, ignore=true, read_file_from_client=true) at 5.5/sql/sql_load.cc:653
      #9  0x0000000000633ef1 in mysql_execute_command (thd=0x7f472fb4b060) at 5.5/sql/sql_parse.cc:3244
      #10 0x000000000063ab1e in mysql_parse (thd=0x7f472fb4b060, rawbuf=0x7f472ae87078 "LOAD DATA LOCAL INFILE '/data/repo/bzr/5.5/mysql-test/var/l.data' INTO TABLE v1 (i)", length=83, parser_state=0x7f472b7b5630) at 5.5/sql/sql_parse.cc:5800
      #11 0x000000000062eb39 in dispatch_command (command=COM_QUERY, thd=0x7f472fb4b060, packet=0x7f472bdee061 "", packet_length=83) at 5.5/sql/sql_parse.cc:1079
      #12 0x000000000062dcc5 in do_command (thd=0x7f472fb4b060) at 5.5/sql/sql_parse.cc:793
      #13 0x000000000072fed6 in do_handle_one_connection (thd_arg=0x7f472fb4b060) at 5.5/sql/sql_connect.cc:1266
      #14 0x000000000072f995 in handle_one_connection (arg=0x7f472fb4b060) at 5.5/sql/sql_connect.cc:1181
      #15 0x0000000000b65695 in pfs_spawn_thread (arg=0x7f472bd57ac0) at 5.5/storage/perfschema/pfs.cc:1015
      #16 0x00007f4731985b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
      #17 0x00007f473029420d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

      Stack trace from

      revision-id: jplindst@mariadb.org-20141103134344-fn99l1w53xyhc43e
      date: 2014-11-03 15:43:44 +0200
      build-date: 2014-11-10 00:42:08 +0400
      revno: 4343
      branch-nick: 5.5

      Also reproducible on maria/10.0.

      MySQL also has problems with this kind of statements, see bug http://bugs.mysql.com/bug.php?id=67878, but it doesn't crash on the scenario above.

      Attachments

        Activity

          Fixed in 5.7.1 (at least the comment at bugs.mysql.com says so)

          elenst Elena Stepanova added a comment - Fixed in 5.7.1 (at least the comment at bugs.mysql.com says so)

          The bug had a wrong description (fixed now), it said that the slave was crashing while in fact it was the master; it shouldn't have been marked as upstream at the first place. But anyway, the upstream replication problem has been fixed now in 5.7.1. Possibly when we fix the crash we'll get the same replication failure and then can consider merging the upstream bugfix.

                  revno: 5107.18.1
                  revision-id: venkatesh.duggirala@oracle.com-20130205051534-wydjb02g7tkuvc31
                  parent: sayantan.dutta@oracle.com-20130204152554-385j9txfp3eh810g
                  committer: Venkatesh Duggirala<venkatesh.duggirala@oracle.com>
                  branch nick: mysql-trunk
                  timestamp: Tue 2013-02-05 10:45:34 +0530
                  message:
                    Bug#15993712-REPLICATION FAILURE ON LOADING DATA INTO
                    A VIEW WITH BINLOG_FORMAT=STATEMENT
                    
                    Replication breaks when a 'LOAD DATA' statement is 
                    used against a view object. There are two problems
                    Problem 1): if field list is not explicitly
                    mentioned, then server expands all fields of the
                    base table, even those that aren't used in the view.
                    Fix: 'All fields' logic should look into view fields
                    only and should not be from the base table.
                    
                    Problem 2): if field list is mentioned, then those
                    fields are expanded as qualified identifiers with base
                    table's name.
                    Eg: column 'i' in 'v1' expanded as `test.t1.i`
                    Fix: Do not expand the columns as qualified identifiers

          elenst Elena Stepanova added a comment - The bug had a wrong description (fixed now), it said that the slave was crashing while in fact it was the master; it shouldn't have been marked as upstream at the first place. But anyway, the upstream replication problem has been fixed now in 5.7.1. Possibly when we fix the crash we'll get the same replication failure and then can consider merging the upstream bugfix. revno: 5107.18.1 revision-id: venkatesh.duggirala@oracle.com-20130205051534-wydjb02g7tkuvc31 parent: sayantan.dutta@oracle.com-20130204152554-385j9txfp3eh810g committer: Venkatesh Duggirala<venkatesh.duggirala@oracle.com> branch nick: mysql-trunk timestamp: Tue 2013-02-05 10:45:34 +0530 message: Bug#15993712-REPLICATION FAILURE ON LOADING DATA INTO A VIEW WITH BINLOG_FORMAT=STATEMENT Replication breaks when a 'LOAD DATA' statement is used against a view object. There are two problems Problem 1): if field list is not explicitly mentioned, then server expands all fields of the base table, even those that aren't used in the view. Fix: 'All fields' logic should look into view fields only and should not be from the base table. Problem 2): if field list is mentioned, then those fields are expanded as qualified identifiers with base table's name. Eg: column 'i' in 'v1' expanded as `test.t1.i` Fix: Do not expand the columns as qualified identifiers

          People

            serg Sergei Golubchik
            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.