Bug in eliminate_item_equal leads to crash in Item_func::Item_func

Bug #601124 reported by Philip Stoev
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MariaDB
Fix Released
High
Timour Katchaounov

Bug Description

When executing the following query, MariaDB 5.3 (and not 5.2 or mysql-server) crashes as follows:

query:

SELECT `col_varchar_key`
FROM (
        SELECT * FROM C
        WHERE ( `col_int_key` ) IN (
                SELECT CHILD_SUBQUERY1_t1 .`col_int_nokey`
                FROM CC CHILD_SUBQUERY1_t1
                STRAIGHT_JOIN C CHILD_SUBQUERY1_t2
                ON CHILD_SUBQUERY1_t2 .`col_varchar_key` = CHILD_SUBQUERY1_t1 .`col_varchar_key`
                WHERE CHILD_SUBQUERY1_t2 .`col_varchar_key` = 'c'
        )
) table1 ;

backtrace:

#3 0x082776c0 in handle_segfault (sig=11) at mysqld.cc:2683
#4 <signal handler called>
#5 0x081ff02b in Item_func::Item_func (this=0xb31bfe8, a=0xb25c9d0, b=0x0) at item_func.h:80
#6 0x081ff0c9 in Item_int_func::Item_int_func (this=0xb31bfe8, a=0xb25c9d0, b=0x0) at item_func.h:338
#7 0x081ff6bd in Item_bool_func2::Item_bool_func2 (this=0xb31bfe8, a=0xb25c9d0, b=0x0) at item_cmpfunc.h:349
#8 0x081ff8a5 in Item_bool_rowready_func2::Item_bool_rowready_func2 (this=0xb31bfe8, a=0xb25c9d0, b=0x0) at item_cmpfunc.h:377
#9 0x081ffad5 in Item_func_eq::Item_func_eq (this=0xb31bfe8, a=0xb25c9d0, b=0x0) at item_cmpfunc.h:482
#10 0x0830c765 in eliminate_item_equal (cond=0xb30cbd8, upper_levels=0x0, item_equal=0xb30cd60) at sql_select.cc:9135
#11 0x0830ca86 in substitute_for_best_equal_field (cond=0xb30cbd8, cond_equal=0xb30cc6c, table_join_idx=0xb30d560) at sql_select.cc:9239
#12 0x082f6b4e in JOIN::optimize (this=0xb3114e8) at sql_select.cc:995
#13 0x082fb8fa in mysql_select (thd=0xb1021a0, rref_pointer_array=0xb25b3d4, tables=0xb25b7b8, wild_num=0, fields=..., conds=0xb25cbd0, og_num=0, order=0x0,
    group=0x0, having=0x0, proc_param=0x0, select_options=2416200192, result=0xb30c078, unit=0xb25b468, select_lex=0xb25b2d0) at sql_select.cc:2364
#14 0x0843a7d9 in mysql_derived_filling (thd=0xb1021a0, lex=0xb1037b4, orig_table_list=0xb30be10) at sql_derived.cc:295
#15 0x0843a0cb in mysql_handle_derived (lex=0xb1037b4, processor=0x843a5f4 <mysql_derived_filling(THD*, LEX*, TABLE_LIST*)>) at sql_derived.cc:56
#16 0x082dda48 in open_and_lock_tables_derived (thd=0xb1021a0, tables=0xb30be10, derived=true) at sql_base.cc:5046
#17 0x0829ac49 in open_and_lock_tables (thd=0xb1021a0, tables=0xb30be10) at mysql_priv.h:1649
#18 0x08294446 in execute_sqlcom_select (thd=0xb1021a0, all_tables=0xb30be10) at sql_parse.cc:5098
#19 0x0828b069 in mysql_execute_command (thd=0xb1021a0) at sql_parse.cc:2318
#20 0x08296857 in mysql_parse (thd=0xb1021a0,
    inBuf=0xb25acc8 "SELECT `col_varchar_key`\nFROM (\nSELECT * FROM C\nWHERE ( `col_int_key` ) IN (\nSELECT CHILD_SUBQUERY1_t1 .`col_int_nokey`\n\t\tFROM CC CHILD_SUBQUERY1_t1\nSTRAIGHT_JOIN C CHILD_SUBQUERY1_t2\nON CHILD_SUBQUER"..., length=330, found_semicolon=0xaeefc228) at sql_parse.cc:6079
#21 0x08288b11 in dispatch_command (command=COM_QUERY, thd=0xb1021a0,
    packet=0xb20d571 "SELECT `col_varchar_key`\nFROM (\nSELECT * FROM C\nWHERE ( `col_int_key` ) IN (\nSELECT CHILD_SUBQUERY1_t1 .`col_int_nokey`\n\t\tFROM CC CHILD_SUBQUERY1_t1\nSTRAIGHT_JOIN C CHILD_SUBQUERY1_t2\nON CHILD_SUBQUER"..., packet_length=331) at sql_parse.cc:1253
#22 0x08287d4f in do_command (thd=0xb1021a0) at sql_parse.cc:891
#23 0x08284e96 in handle_one_connection (arg=0xb1021a0) at sql_connect.cc:1599
#24 0x00a08919 in start_thread () from /lib/libpthread.so.0
#25 0x00951e5e in clone () from /lib/libc.so.6

Notice that b = 0x0 , which gets propagated from eliminate_item_equal()

(gdb) list
9130 if (produce_equality)
9131 {
9132 if (eq_item)
9133 eq_list.push_back(eq_item);
9134
9135 eq_item= new Item_func_eq(item_field, current_sjm? current_sjm_head: head);
9136
9137 if (!eq_item)
9138 return 0;
9139 eq_item->set_cmp_func();

(gdb) print current_sjm
$3 = (TABLE_LIST *) 0xb30c650

(gdb) print current_sjm_head
$1 = (Item *) 0x0

Related branches

Revision history for this message
Philip Stoev (pstoev-askmonty) wrote :

Test case:

--disable_warnings
DROP TABLE /*! IF EXISTS */ CC;
DROP TABLE /*! IF EXISTS */ C;
--enable_warnings

CREATE TABLE `CC` (
  `col_int_nokey` int(11) DEFAULT NULL,
  `col_int_key` int(11) DEFAULT NULL,
  `col_varchar_key` varchar(1) DEFAULT NULL,
  KEY `col_int_key` (`col_int_key`),
  KEY `col_varchar_key` (`col_varchar_key`,`col_int_key`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
INSERT INTO `CC` VALUES (7,8,'v');
INSERT INTO `CC` VALUES (1,9,'r');
INSERT INTO `CC` VALUES (5,9,'a');
INSERT INTO `CC` VALUES (3,186,'m');
INSERT INTO `CC` VALUES (6,NULL,'y');
INSERT INTO `CC` VALUES (92,2,'j');
INSERT INTO `CC` VALUES (7,3,'d');
INSERT INTO `CC` VALUES (NULL,0,'z');
INSERT INTO `CC` VALUES (3,133,'e');
INSERT INTO `CC` VALUES (5,1,'h');
INSERT INTO `CC` VALUES (1,8,'b');
INSERT INTO `CC` VALUES (2,5,'s');
INSERT INTO `CC` VALUES (NULL,5,'e');
INSERT INTO `CC` VALUES (1,8,'j');
INSERT INTO `CC` VALUES (0,6,'e');
INSERT INTO `CC` VALUES (210,51,'f');
INSERT INTO `CC` VALUES (8,4,'v');
INSERT INTO `CC` VALUES (7,7,'x');
INSERT INTO `CC` VALUES (5,6,'m');
INSERT INTO `CC` VALUES (NULL,4,'c');
CREATE TABLE `C` (
  `col_int_nokey` int(11) DEFAULT NULL,
  `col_int_key` int(11) DEFAULT NULL,
  `col_varchar_key` varchar(1) DEFAULT NULL,
  KEY `col_int_key` (`col_int_key`),
  KEY `col_varchar_key` (`col_varchar_key`,`col_int_key`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
INSERT INTO `C` VALUES (NULL,2,'w');
INSERT INTO `C` VALUES (7,9,'m');
INSERT INTO `C` VALUES (9,3,'m');
INSERT INTO `C` VALUES (7,9,'k');
INSERT INTO `C` VALUES (4,NULL,'r');
INSERT INTO `C` VALUES (2,9,'t');
INSERT INTO `C` VALUES (6,3,'j');
INSERT INTO `C` VALUES (8,8,'u');
INSERT INTO `C` VALUES (NULL,8,'h');
INSERT INTO `C` VALUES (5,53,'o');
INSERT INTO `C` VALUES (NULL,0,NULL);
INSERT INTO `C` VALUES (6,5,'k');
INSERT INTO `C` VALUES (188,166,'e');
INSERT INTO `C` VALUES (2,3,'n');
INSERT INTO `C` VALUES (1,0,'t');
INSERT INTO `C` VALUES (1,1,'c');
INSERT INTO `C` VALUES (0,9,'m');
INSERT INTO `C` VALUES (9,5,'y');
INSERT INTO `C` VALUES (NULL,6,'f');
INSERT INTO `C` VALUES (4,2,'d');

SELECT `col_varchar_key`
FROM (
        SELECT * FROM C
        WHERE ( `col_int_key` ) IN (
                SELECT CHILD_SUBQUERY1_t1 .`col_int_nokey`
                FROM CC CHILD_SUBQUERY1_t1
                STRAIGHT_JOIN C CHILD_SUBQUERY1_t2
                ON CHILD_SUBQUERY1_t2 .`col_varchar_key` = CHILD_SUBQUERY1_t1 .`col_varchar_key`
                WHERE CHILD_SUBQUERY1_t2 .`col_varchar_key` = 'c'
        )
) table1 ;

DROP TABLE CC;
DROP TABLE C;

Changed in maria:
milestone: none → 5.3
Revision history for this message
Philip Stoev (pstoev-askmonty) wrote :

Still reproducible with

revision-id: <email address hidden>
date: 2011-02-12 18:43:22 +0100
build-date: 2011-02-14 10:38:52 +0200
revno: 2907
branch-nick: maria-5.3

Changed in maria:
assignee: nobody → Timour Katchaounov (timour)
Revision history for this message
Philip Stoev (pstoev-askmonty) wrote :

See also bug 718593

Revision history for this message
Philip Stoev (pstoev-askmonty) wrote :

Simplified test case:

CREATE TABLE t1 ( f1 int(11), f3 varchar(1)) ;
INSERT INTO t1 VALUES (5,'m'),(NULL,'c');

CREATE TABLE t2 ( f2 int(11), f3 varchar(1)) ;
INSERT INTO t2 VALUES (6,'f'),(2,'d');

CREATE TABLE t3 ( f2 int(11), f3 varchar(1)) ;
INSERT INTO t3 VALUES (6,'f'),(2,'d');

SELECT * FROM t3
WHERE ( f2 ) IN (
        SELECT t1.f1
        FROM t1
        STRAIGHT_JOIN t2
        ON t2.f3 = t1.f3
        WHERE t2.f3 = 'c'
);

Revision history for this message
Timour Katchaounov (timour) wrote :

The bug is reproducible in 5.3-mwl89 with
set @@optimizer_switch='materialization=on';

Changed in maria:
status: New → Confirmed
importance: Undecided → Low
importance: Low → High
Changed in maria:
status: Confirmed → In Progress
Revision history for this message
Timour Katchaounov (timour) wrote :

The bug has been fixed by the patch for LP BUG#718578, where
the patch changes make_cond_for_table() to call fix_fields()
instead of quick_fix_field() for the newly created AND/OR
items. This change ensures that all child Items' properties
are properly propagated to the new Items.

Changed in maria:
status: In Progress → Invalid
status: Invalid → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.