[MDEV-3940] Server crash or assertion `item->type() == Item::STRING_ITEM' failure on LOAD DATA through a view with statement binary logging Created: 2012-12-15  Updated: 2014-12-01  Resolved: 2014-11-19

Status: Closed
Project: MariaDB Server
Component/s: Views
Affects Version/s: 10.0.0, 5.5.28a, 5.5, 10.0
Fix Version/s: 5.5.41, 10.0.15

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: upstream-fixed

Issue Links:
Relates

 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.



 Comments   
Comment by Elena Stepanova [ 2013-04-28 ]

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

Comment by Elena Stepanova [ 2014-11-09 ]

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

Generated at Thu Feb 08 06:52:26 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.