| Bug #58553 | Queries with pushed conditions causes 'explain extended' to crash mysqld | ||
|---|---|---|---|
| Submitted: | 29 Nov 2010 10:22 | Modified: | 12 Jan 2011 18:07 |
| Reporter: | Jan Wedvik | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Optimizer | Severity: | S2 (Serious) |
| Version: | next-mr, 5.5, 5.1.x | OS: | Any |
| Assigned to: | Jan Wedvik | CPU Architecture: | Any |
[29 Nov 2010 12:46]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/125336 3477 Jan Wedvik 2010-11-29 Fix for bug#58553, "Queries with pushed conditions causes 'explain extended' to crash mysqld". handler::pushed_cond was not always properly reset when table objects where recycled via the table cache. handler::pushed_cond is now set to NULL in handler::ha_reset(). This should prevent pushed conditions from (incorrectly) re-apperaring in later queries.
[29 Nov 2010 15:40]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/125365 3354 Jan Wedvik 2010-11-29 This is a temporary fix for bug #58553, until a permanent fix can be merged from server trunk (e.g. mysql-5.1 branch). This fix only modifies cluster-specific code.
[29 Nov 2010 15:41]
Bugs System
Pushed into mysql-5.1-telco-6.3 5.1.51-ndb-6.3.40 (revid:jan.wedvik@sun.com-20101129153949-qg0m6z9bx1hph93s) (version source revid:jan.wedvik@sun.com-20101129153949-qg0m6z9bx1hph93s) (merge vers: 5.1.51-ndb-6.3.40) (pib:23)
[29 Nov 2010 15:45]
Bugs System
Pushed into mysql-5.1-telco-7.0 5.1.51-ndb-7.0.21 (revid:jonas@mysql.com-20101129154351-ebqx7i9fba29hq5o) (version source revid:jonas@mysql.com-20101129154351-ebqx7i9fba29hq5o) (merge vers: 5.1.51-ndb-7.0.21) (pib:23)
[29 Nov 2010 22:40]
Sveta Smirnova
Thank you for the report. I can not repeat described behavior nor in mysql-trunk, neither in 5.5-telco. Which configuration options do you use?
[30 Nov 2010 10:50]
Jonas Oreland
A "temporary fix" has been pushed to 6.3.40, 7.0.21 and 7.1.10 Setting status to documenting... When it has been documented, it should be reset to old state (or a new bug should be opened instead maybe)
[30 Nov 2010 10:53]
Jonas Oreland
note: also changing category to cluster, please reset once documenting.
[30 Nov 2010 13:11]
Jan Wedvik
Shell script for reproducing the error
Attachment: rep58553.sh (application/x-shellscript, text), 2.23 KiB.
[30 Nov 2010 13:15]
Jan Wedvik
I have added a script that repeats the steps that I did in order to get the error. I have tried this on two different machines with config as follows: 1: Linux atum17 2.6.35-22-generic #34-Ubuntu SMP Sun Oct 10 09:26:05 UTC 2010 x86_64 GNU/Linux gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) 2: Linux fimafeng09 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)
[30 Nov 2010 13:55]
Jon Stephens
Documented bugfix in the NDB-6.3.40, 7.0.21, 7.1.10 changelogs as follows:
Issuing EXPLAIN EXTENDED with a query that would use condition
pushdown could cause mysqld to crash.
Closed.
[30 Nov 2010 13:57]
Jon Stephens
Setting category/status back to Optimizer/Need Feedback (after closing for Cluster fix) per discussion today with Jonas (so this can hopefully be fixed later in mainline trees).
[1 Dec 2010 11:51]
Susanne Ebrecht
Set back to verified.
[11 Jan 2011 11:10]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/128409 3540 Jan Wedvik 2011-01-11 Fix for bug#58553, "Queries with pushed conditions causes 'explain extended' to crash mysqld". handler::pushed_cond was not always properly reset when table objects where recycled via the table cache. handler::pushed_cond is now set to NULL in handler::ha_reset(). This should prevent pushed conditions from (incorrectly) re-apperaring in later queries.
[11 Jan 2011 11:34]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/128411 3234 Jan Wedvik 2011-01-11 [merge] Merge of fix for bug#58553, "Queries with pushed conditions causes 'explain extended' to crash mysqld" (see http://lists.mysql.com/commits/128409).
[11 Jan 2011 11:45]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/128413 3484 Jan Wedvik 2011-01-11 [merge] Merge of fix for bug#58553, "Queries with pushed conditions causes 'explain extended' to crash mysqld" (see http://lists.mysql.com/commits/128409).
[11 Jan 2011 11:47]
Bugs System
Pushed into mysql-trunk 5.6.2 (revid:jan.wedvik@sun.com-20110111114502-dxuh0qvribnaty25) (version source revid:jan.wedvik@sun.com-20110111114502-dxuh0qvribnaty25) (merge vers: 5.6.2) (pib:24)
[11 Jan 2011 11:48]
Bugs System
Pushed into mysql-5.5 5.5.9 (revid:jan.wedvik@sun.com-20110111113328-fd4q0pn7fca1ztmt) (version source revid:jan.wedvik@sun.com-20110111113328-fd4q0pn7fca1ztmt) (merge vers: 5.5.9) (pib:24)
[11 Jan 2011 11:49]
Bugs System
Pushed into mysql-5.1 5.1.55 (revid:jan.wedvik@sun.com-20110111110954-fwj6rsugt2ulywa9) (version source revid:jan.wedvik@sun.com-20110111110954-fwj6rsugt2ulywa9) (merge vers: 5.1.55) (pib:24)
[12 Jan 2011 13:07]
Ole John Aske
Fix pushed to mysql-5.1, mysql-5.5 and mysql-trunk
[12 Jan 2011 18:07]
Paul DuBois
Noted in 5.5.9, 5.6.2 changelogs.
[31 Jan 2011 16:17]
Jon Stephens
Also noted in the 5.1.55 changelog.
Description: Running certain sequences of queries, some of which have predicates that will be pushed to the storage engine, causes mysqld to crash. The problem appears to be that the handler::pushed_cond field is not reset before TABLE objects are returned to the table cache. When a another query is executed, the table cache may thus return a TABLE object where file->pushed_cond points to memory once occupied by a condition of the previous query. There is code in make_join_select() to reset 'pushed_cond', but apparently this code is not always executed before calling select_describe(). How to repeat: Running the following sql script causes mysqld to crash: ------------------------8<---------------------- drop database if exists spj_ndb; create database spj_ndb; use spj_ndb; create table t1 ( a int not null, b int not null, c int not null, d int not null, primary key (`a`,`b`) ) engine = ndb; explain extended select * from t1 join t1 as t2 on t1.c=1 where t2.c=1; explain extended select straight_join * from t1 join t1 as t2 on t2.a = t1.a and t2.b = t1.b join t1 as t3 on t3.a = t1.c and t3.b = t1.d join t1 as t4 on t4.a = t3.b and t4.b = t2.c; explain extended select t2.c, count(distinct t2.a) from t1 join t1 as t2 on t1.a = t2.c and t1.b = t2.d where t2.a = 4 group by t2.c; explain extended select * from t1 join t1 as t2 on t1.c=1 where t2.c=1; explain extended select t2.c, count(distinct t2.a) from t1 join t1 as t2 on t1.a = t2.c and t1.b = t2.d where t2.a = 4 group by t2.c; ------------------------8<---------------------- gdb gives the following output: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2ae3d7319710 (LWP 22106)] 0x000000000000ffff in ?? () (gdb) where #0 0x000000000000ffff in ?? () #1 0x000000000061b971 in select_describe (join=0x27573e8, need_tmp_table=false, need_order=true, distinct=false, message=0x0) at /export/home2/tmp/jw159207/mysql/repo/mysql-next-mr/sql/sql_select.cc:22836 #2 0x00000000005ebbb3 in JOIN::exec (this=0x27573e8) at /export/home2/tmp/jw159207/mysql/repo/mysql-next-mr/sql/sql_select.cc:2853 #3 0x00000000005edd5c in mysql_select (thd=0x27091e0, rref_pointer_array=0x270b638, tables=0x274e750, wild_num=0, fields=..., conds=0x27569e8, og_num=1, order=0x0, group=0x2756c58, having=0x0, proc_param=0x0, select_options=2147748612, result=0x2756d28, unit=0x270ae18, select_lex=0x270b450) at /export/home2/tmp/jw159207/mysql/repo/mysql-next-mr/sql/sql_select.cc:3496 #4 0x000000000061c61d in mysql_explain_union (thd=0x27091e0, unit=0x270ae18, result=0x2756d28) at /export/home2/tmp/jw159207/mysql/repo/mysql-next-mr/sql/sql_select.cc:23049 #5 0x00000000005c70cf in execute_sqlcom_select (thd=0x27091e0, all_tables=0x274e750) at /export/home2/tmp/jw159207/mysql/repo/mysql-next-mr/sql/sql_parse.cc:4468 #6 0x00000000005c00fe in mysql_execute_command (thd=0x27091e0) at /export/home2/tmp/jw159207/mysql/repo/mysql-next-mr/sql/sql_parse.cc:2092 #7 0x00000000005c9433 in mysql_parse (thd=0x27091e0, rawbuf=0x274e220 "explain extended\nselect t2.c, count(distinct t2.a)\nfrom t1\njoin t1 as t2 on t1.a = t2.c and t1.b = t2.d\nwhere t2.a = 4\ngroup by t2.c", length=132, parser_state=0x2ae3d7318180) at /export/home2/tmp/jw159207/mysql/repo/mysql-next-mr/sql/sql_parse.cc:5537 #8 0x00000000005bda1e in dispatch_command (command=COM_QUERY, thd=0x27091e0, packet=0x27461f1 "", packet_length=132) at /export/home2/tmp/jw159207/mysql/repo/mysql-next-mr/sql/sql_parse.cc:1056 #9 0x00000000005bd06b in do_command (thd=0x27091e0) at /export/home2/tmp/jw159207/mysql/repo/mysql-next-mr/sql/sql_parse.cc:796 #10 0x000000000069f7b0 in do_handle_one_connection (thd_arg=0x27091e0) at /export/home2/tmp/jw159207/mysql/repo/mysql-next-mr/sql/sql_connect.cc:745 #11 0x000000000069f60b in handle_one_connection (arg=0x27091e0) at /export/home2/tmp/jw159207/mysql/repo/mysql-next-mr/sql/sql_connect.cc:684 #12 0x00002ae3c9125971 in start_thread () from /lib/libpthread.so.0 #13 0x00002ae3ca20791d in clone () from /lib/libc.so.6 #14 0x0000000000000000 in ?? () This error was first seen in mysql-5.1-telco-7.0. It can also be reproduced in mysql-next-mr. Ndb is the only storage engine using condition pushdown, and mysql-next-mr does not have ndb (not compilable via cmake anyway), one must alter the source in order to emulate condition pushdown. This can be done using the following patch (relative to mysql-next-mr, revno 3206): ------------------------8<---------------------- === modified file 'sql/handler.h' --- sql/handler.h 2010-11-05 16:23:32 +0000 +++ sql/handler.h 2010-11-25 13:16:59 +0000 @@ -2162,7 +2162,7 @@ public: Calls to rnd_init/rnd_end, index_init/index_end etc do not affect the condition stack. */ - virtual const Item *cond_push(const Item *cond) { return cond; }; + virtual const Item *cond_push(const Item *cond) { return NULL; }; /** Pop the top condition from the condition stack of the handler instance. ------------------------8<---------------------- Suggested fix: Set pushed_cond to null in handler::reset(), to ensure that this field is null before the table object is returned to the table cache.