Bug #37362 Crash in do_field_eq
| Submitted: | 12 Jun 2008 11:30 | Modified: | 3 Aug 2009 23:05 |
|---|---|---|---|
| Reporter: | Philip Stoev | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Optimizer | Severity: | S1 (Critical) |
| Version: | 6.0-falcon, 5.0, 5.1, 6.0 bzr | OS: | Any |
| Assigned to: | Gleb Shchepa | CPU Architecture: | Any |
| Tags: | regression | ||
[2 Sep 2008 13:37]
Philip Stoev
Setting to open so that the bug verification team can take over.
[23 Mar 2009 21:38]
Sveta Smirnova
Thank you for the report.
Verified as described.
Backtrace from 5.1:
Thread 1 (process 4827):
#0 0x002ce402 in __kernel_vsyscall ()
#1 0x0046264f in pthread_kill () from /lib/libpthread.so.0
#2 0x085a46c5 in my_write_core (sig=11) at stacktrace.c:310
#3 0x0824c685 in handle_segfault (sig=11) at mysqld.cc:2513
#4 <signal handler called>
#5 0x08190d80 in Item_field::print (this=0xa295ae0, str=0xb2b0c3f4, query_type=QT_ORDINARY) at item.cc:5434
#6 0x0816f657 in st_select_lex::print_order (str=0xb2b0c3f4, order=0xa28ac58, query_type=QT_ORDINARY) at sql_lex.cc:1985
#7 0x082eef48 in st_select_lex::print (this=0xa289638, thd=0xa230c78, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_select.cc:16634
#8 0x08207766 in subselect_single_select_engine::print (this=0xa2854a8, str=0xb2b0c3f4, query_type=QT_ORDINARY) at item_subselect.cc:2438
#9 0x0820153f in Item_subselect::print (this=0xa285420, str=0xb2b0c3f4, query_type=QT_ORDINARY) at item_subselect.cc:317
#10 0x081842c1 in Item::print_item_w_name (this=0xa285420, str=0xb2b0c3f4, query_type=QT_ORDINARY) at item.cc:451
#11 0x082eedbe in st_select_lex::print (this=0xa289238, thd=0xa230c78, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_select.cc:16595
#12 0x0816f786 in st_select_lex_unit::print (this=0xa2893c8, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_lex.cc:1953
#13 0x082ee6ab in TABLE_LIST::print (this=0xa285d48, thd=0xa230c78, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_select.cc:16487
#14 0x082ee9f6 in print_join (thd=0xa230c78, str=0xb2b0c3f4, tables=0xa2320d4, query_type=QT_ORDINARY) at sql_select.cc:16390
#15 0x082eee2a in st_select_lex::print (this=0xa232010, thd=0xa230c78, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_select.cc:16606
#16 0x0816f786 in st_select_lex_unit::print (this=0xa231da0, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_lex.cc:1953
#17 0x0825b7d0 in execute_sqlcom_select (thd=0xa230c78, all_tables=0xa285d48) at sql_parse.cc:4895
#18 0x08261be1 in mysql_execute_command (thd=0xa230c78) at sql_parse.cc:2204
#19 0x0826af74 in mysql_parse (thd=0xa230c78,
inBuf=0xa288cc0 "EXPLAIN EXTENDED SELECT int_key FROM ( SELECT ( SELECT COUNT( pk ) FROM ( SELECT AVG(\nint_nokey ) FROM D AS X WHERE X . int_key < 76 ORDER BY int_nokey LIMIT 20 ) AS X WHERE X\n. int_nokey < 83 GROUP"..., length=317, found_semicolon=0xb2b0d2fc) at sql_parse.cc:5831
#20 0x0826bbb0 in dispatch_command (command=COM_QUERY, thd=0xa230c78, packet=0xb2a7d021 "", packet_length=317) at sql_parse.cc:1216
#21 0x0826cdce in do_command (thd=0xa230c78) at sql_parse.cc:857
#22 0x08259a05 in handle_one_connection (arg=0xa230c78) at sql_connect.cc:1115
#23 0x0045fbd4 in start_thread () from /lib/libpthread.so.0
#24 0x003b74fe in clone () from /lib/libc.so.6
[23 Mar 2009 21:40]
Sveta Smirnova
6.0 backtrace like 5.1 in my case:
#0 0x002ce402 in __kernel_vsyscall ()
#0 0x002ce402 in __kernel_vsyscall ()
#1 0x0046264f in pthread_kill () from /lib/libpthread.so.0
#2 0x088240fb in my_write_core (sig=11) at stacktrace.c:309
#3 0x082bf3a0 in handle_segfault (sig=11) at mysqld.cc:2689
#4 <signal handler called>
#5 0x082004c4 in Item_field::print (this=0xa7990f8, str=0xa7f0d084, query_type=QT_ORDINARY) at item.cc:5624
#6 0x081df05b in st_select_lex::print_order (str=0xa7f0d084, order=0xa5f4128, query_type=QT_ORDINARY) at sql_lex.cc:2055
#7 0x083702e8 in st_select_lex::print (this=0xa5b72d8, thd=0xa5ba5b8, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_select.cc:22125
#8 0x08277b50 in subselect_single_select_engine::print (this=0xa5f4258, str=0xa7f0d084, query_type=QT_ORDINARY) at item_subselect.cc:2783
#9 0x08271a51 in Item_subselect::print (this=0xa5f41b8, str=0xa7f0d084, query_type=QT_ORDINARY) at item_subselect.cc:383
#10 0x081f34a7 in Item::print_item_w_name (this=0xa5f41b8, str=0xa7f0d084, query_type=QT_ORDINARY) at item.cc:450
#11 0x0837015e in st_select_lex::print (this=0xa5b6ea8, thd=0xa5ba5b8, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_select.cc:22086
#12 0x081df18a in st_select_lex_unit::print (this=0xa5b7040, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_lex.cc:2023
#13 0x0836f999 in TABLE_LIST::print (this=0xa5f4d90, thd=0xa5ba5b8, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_select.cc:21978
#14 0x0836fc48 in print_table_array (thd=0xa5ba5b8, str=0xa7f0d084, table=0xa7996c8, end=0xa7996cc) at sql_select.cc:21834
#15 0x0836febe in print_join (thd=0xa5ba5b8, str=0xa7f0d084, tables=0xa5bb8b0, query_type=QT_ORDINARY) at sql_select.cc:21903
#16 0x083701ca in st_select_lex::print (this=0xa5bb7ec, thd=0xa5ba5b8, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_select.cc:22097
#17 0x081df18a in st_select_lex_unit::print (this=0xa5bb554, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_lex.cc:2023
#18 0x082ce382 in execute_sqlcom_select (thd=0xa5ba5b8, all_tables=0xa5f4d90) at sql_parse.cc:4752
#19 0x082d4017 in mysql_execute_command (thd=0xa5ba5b8) at sql_parse.cc:2069
#20 0x082dced3 in mysql_parse (thd=0xa5ba5b8,
inBuf=0xa5b66c8 "EXPLAIN EXTENDED SELECT int_key FROM ( SELECT ( SELECT COUNT( pk ) FROM ( SELECT AVG(\nint_nokey ) FROM D AS X WHERE X . int_key < 76 ORDER BY int_nokey LIMIT 20 ) AS X WHERE X\n. int_nokey < 83 GROUP"..., length=317, found_semicolon=0xa7f0df20) at sql_parse.cc:5783
#21 0x082dd915 in dispatch_command (command=COM_QUERY, thd=0xa5ba5b8, packet=0xa7e7e021 "", packet_length=317) at sql_parse.cc:1009
#22 0x082dec79 in do_command (thd=0xa5ba5b8) at sql_parse.cc:691
#23 0x082cca67 in handle_one_connection (arg=0xa5ba5b8) at sql_connect.cc:1146
#24 0x0045fbd4 in start_thread () from /lib/libpthread.so.0
#25 0x003b74fe in clone () from /lib/libc.so.6
[23 Mar 2009 21:42]
Sveta Smirnova
shorter test
Attachment: bug37362.test (application/octet-stream, text), 379.17 KiB.
[24 Mar 2009 6:50]
Sveta Smirnova
Bug was repeatable with version 5.1.23, then not repeatable with versions 5.1.30-5.1.32 (didn't check when it was reintroduced though) and 6.0.8, then repeatable again with current development sources.
[24 Mar 2009 17:12]
Sveta Smirnova
Bug is repeatable with current 5.0, 5.1 and 6.0 sources.
[1 Apr 2009 21:56]
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/71146 2722 Gleb Shchepa 2009-04-02 Bug #37362: Crash in do_field_eq EXPLAIN EXTENDED of nested query containing a error: 1054 Unknown column '...' in 'field list' may cause a server crash. Parse error like described above forces a call to JOIN::destroy() on malformed subquery. That JOIN::destroy function closes and frees temporary tables. However, temporary fields of these tables may be listed in st_select_lex::group_list of outer query, and that st_select_lex may not cleanup them properly. So, after the JOIN::destroy call that st_select_lex::group_list may have Item_field objects with dangling pointers to freed temporary table Field objects. That caused a crash. To prevent dangling pointers, 1) a list of temporary table fields has been added to JOIN class; 2) JOIN::destroy has been modified to cleanup temporary table fields. modified: mysql-test/r/subselect3.result mysql-test/t/subselect3.test sql/sql_select.cc sql/sql_select.h
[3 Apr 2009 15:44]
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/71332 2722 Gleb Shchepa 2009-04-03 Bug #37362: Crash in do_field_eq EXPLAIN EXTENDED of nested query containing a error: 1054 Unknown column '...' in 'field list' may cause a server crash. Parse error like described above forces a call to JOIN::destroy() on malformed subquery. That JOIN::destroy function closes and frees temporary tables. However, temporary fields of these tables may be listed in st_select_lex::group_list of outer query, and that st_select_lex may not cleanup them properly. So, after the JOIN::destroy call that st_select_lex::group_list may have Item_field objects with dangling pointers to freed temporary table Field objects. That caused a crash. modified: mysql-test/r/subselect3.result mysql-test/t/subselect3.test sql/sql_select.cc
[29 Apr 2009 18:15]
Timour Katchaounov
Review discussion with Gleb:
<timour> gleb, quick question
<timour> in
<timour> JOIN::destroy()
<timour> you added:
<timour> + { /* Cleanup items referencing temporary table columns */
<timour> + List_iterator_fast<Item> it(tmp_all_fields3);
<timour> + Item *item;
<timour> + while ((item= it++))
<timour> + item->cleanup();
<timour> + }
<timour> gleb, this is unconditional, however
<timour> looking at how tmp_all_fields3 is used,
<timour> one case that it is initialized inside an IF statement:
<timour> inside
<timour> JOIN::exec()
<timour> {
<timour> ....
<timour> if (curr_join->group || curr_join->tmp_table_param.sum_func_count ||
<timour> (procedure && (procedure->flags & PROC_GROUP)))
<timour> {
<timour> ...
<gleb> timour: looking
<timour> initalize and modify tmp_all_fields3
<timour> ...
<timour> }
<timour> }
<timour> gleb, thus, it makes sense to change your patch as:
<timour> if (tmp_all_fields3 is non-empty)
<timour> {
<timour> cleanup all items in tmp_all_fields3
<timour> }
<timour> gleb, then another question -
<gleb> timour: agree (OTOH isn't this change equivalent to my patch? ;-)
<timour> gleb, not exactly, as with this change we allocate an iterator only if really needed.
<timour> gleb, and it is clearer, otherwise why cleanup something that shouldn't be cleaned up.
<timour> gleb, then naturally, I would like you to investigate how do we cleanup the contents of
<timour> tmp_all_fields[1,2]
<gleb> timour: FYI: cleanup of tmp_all_fields2 like tmp_all_fields3 is probably ok, but tmp_all_fields1 is not (I'm just running tests and looking at gdb traces)
<timour> gleb, could be - my point was that we should not wait for the next similar bug if there are other similar cases.
<timour> gleb, also, please add a comment why tmp_all_fields[2,3] can be cleaned up, but tmp_all_fields1 cannot.
<gleb> timour: I see. but additional investigation is not trivial (need some more time)
<gleb> timour: ok
<timour> gleb, if tmp_all_fields2 needs cleanup, could you add a test.
<gleb> timour: I think I can
[30 Apr 2009 8:36]
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/73090 2722 Gleb Shchepa 2009-04-30 Bug #37362: Crash in do_field_eq EXPLAIN EXTENDED of nested query containing a error: 1054 Unknown column '...' in 'field list' may cause a server crash. Parse error like described above forces a call to JOIN::destroy() on malformed subquery. That JOIN::destroy function closes and frees temporary tables. However, temporary fields of these tables may be listed in st_select_lex::group_list of outer query, and that st_select_lex may not cleanup them properly. So, after the JOIN::destroy call that st_select_lex::group_list may have Item_field objects with dangling pointers to freed temporary table Field objects. That caused a crash. @ mysql-test/r/subselect3.result Added test case for bug #37362. @ mysql-test/t/subselect3.test Added test case for bug #37362. @ sql/sql_select.cc Bug #37362: Crash in do_field_eq The JOIN::destroy function has been modified to cleanup temporary table column items.
[28 May 2009 7:40]
Bugs System
Pushed into 5.0.83 (revid:joro@sun.com-20090528073529-q9b8s60vlpu28fny) (version source revid:gshchepa@mysql.com-20090430192037-9p1etcynkglte2j3) (merge vers: 5.0.82) (pib:6)
[28 May 2009 8:13]
Bugs System
Pushed into 5.1.36 (revid:joro@sun.com-20090528073639-yohsb4q1jzg7ycws) (version source revid:mats@sun.com-20090511132802-nnkiyb2huih1tklz) (merge vers: 5.1.35) (pib:6)
[30 May 2009 2:35]
Paul DuBois
Noted in 5.0.83, 5.1.36 changelogs. If a query was such as to produce the error "1054 Unknown column '...' in 'field list'," using EXPLAIN EXTENDED with the query could cause a server crash. Setting report to NDI pending push into 6.0.x.
[3 Aug 2009 23:05]
Paul DuBois
Noted in 5.4.4 changelog.
[10 Aug 2009 17:53]
Paul DuBois
Noted in 5.0.82sp1 changelog.
[10 Aug 2009 18:59]
Bugs System
Pushed into 5.0.85 (revid:build@mysql.com-20090810185326-yr4orhpwq09e3y50) (version source revid:build@mysql.com-20090810185326-yr4orhpwq09e3y50) (merge vers: 5.0.85) (pib:11)
[12 Aug 2009 22:54]
Paul DuBois
Noted in 5.4.2 changelog because next 5.4 version will be 5.4.2 and not 5.4.4.
[15 Aug 2009 2:11]
Paul DuBois
Ignore previous comment about 5.4.2.
[25 Aug 2009 9:23]
Bugs System
Pushed into 5.1.39 (revid:jperkin@sun.com-20090824091334-6ktgrhq218vl7zq1) (version source revid:joerg@mysql.com-20090813203300-nnskc3aofxydzi85) (merge vers: 5.1.39) (pib:11)
[26 Aug 2009 13:45]
Bugs System
Pushed into 5.1.37-ndb-7.0.8 (revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)
[26 Aug 2009 13:46]
Bugs System
Pushed into 5.1.37-ndb-6.3.27 (revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (version source revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (merge vers: 5.1.37-ndb-6.3.27) (pib:11)
[26 Aug 2009 13:48]
Bugs System
Pushed into 5.1.37-ndb-6.2.19 (revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (version source revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (merge vers: 5.1.37-ndb-6.2.19) (pib:11)
[27 Aug 2009 16:32]
Bugs System
Pushed into 5.1.35-ndb-7.1.0 (revid:magnus.blaudd@sun.com-20090827163030-6o3kk6r2oua159hr) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)
[14 Sep 2009 16:02]
Bugs System
Pushed into 5.4.4-alpha (revid:alik@sun.com-20090914155317-m1g9wodmndzdj4l1) (version source revid:alik@sun.com-20090914155317-m1g9wodmndzdj4l1) (merge vers: 5.4.4-alpha) (pib:11)
[1 Oct 2009 5:58]
Bugs System
Pushed into 5.1.39-ndb-6.3.28 (revid:jonas@mysql.com-20091001055605-ap2kiaarr7p40mmv) (version source revid:jonas@mysql.com-20091001055605-ap2kiaarr7p40mmv) (merge vers: 5.1.39-ndb-6.3.28) (pib:11)
[1 Oct 2009 7:25]
Bugs System
Pushed into 5.1.39-ndb-7.0.9 (revid:jonas@mysql.com-20091001072547-kv17uu06hfjhgjay) (version source revid:jonas@mysql.com-20091001071652-irejtnumzbpsbgk2) (merge vers: 5.1.39-ndb-7.0.9) (pib:11)
[1 Oct 2009 13:25]
Bugs System
Pushed into 5.1.39-ndb-7.1.0 (revid:jonas@mysql.com-20091001123013-g9ob2tsyctpw6zs0) (version source revid:jonas@mysql.com-20091001123013-g9ob2tsyctpw6zs0) (merge vers: 5.1.39-ndb-7.1.0) (pib:11)
[5 Oct 2009 10:50]
Bugs System
Pushed into 5.1.39-ndb-6.2.19 (revid:jonas@mysql.com-20091005103850-dwij2dojwpvf5hi6) (version source revid:jonas@mysql.com-20090930185117-bhud4ek1y0hsj1nv) (merge vers: 5.1.39-ndb-6.2.19) (pib:11)
[8 Oct 2009 20:13]
Paul DuBois
The 5.4 fix has been pushed to 5.4.2.
Portions of this website are copyright © 2001, 2002 The PHP Group
Page generated in 0.102 sec. using MySQL 8.4.7-u6-cloud
Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the
respective copyright holders.
It is not reviewed in advance
by Oracle and does not necessarily represent the opinion of
Oracle or any other party.
Description: When running EXPLAIN EXTENDED, mysql crashed as follows: #0 0x00110416 in __kernel_vsyscall () #1 0x00581c78 in pthread_kill () from /lib/libpthread.so.0 #2 0x0843eda3 in write_core (sig=11) at stacktrace.c:302 #3 0x0829b228 in handle_segfault (sig=11) at mysqld.cc:2626 #4 <signal handler called> #5 0x00432f61 in memcpy () from /lib/libc.so.6 #6 0x083f851d in do_field_eq (copy=0xae80d44) at field_conv.cc:32 #7 0x0830e542 in copy_fields (param=0xaf5fbbc) at sql_select.cc:17642 #8 0x083103c6 in end_send_group (join=0xaf5e968, join_tab=0x0, end_of_records=false) at sql_select.cc:14563 #9 0x08322c1c in do_select (join=0xaf5e968, fields=0xaf5fcc4, table=0x0, procedure=0x0) at sql_select.cc:13069 #10 0x08335655 in JOIN::exec (this=0xaf5e968) at sql_select.cc:2740 #11 0x0824f73b in subselect_single_select_engine::exec (this=0xaf73830) at item_subselect.cc:2277 #12 0x0824c10e in Item_subselect::exec (this=0xaf73790) at item_subselect.cc:280 #13 0x0824cf8b in Item_singlerow_subselect::val_int (this=0xaf73790) at item_subselect.cc:629 #14 0x081ddb06 in Item::save_in_field (this=0xaf73790, field=0xaf233a0, no_conversions=false) at item.cc:4886 #15 0x082e7765 in fill_record (thd=0xa9c09c90, ptr=0xae49dec, values=@0xae800fc, ignore_errors=true) at sql_base.cc:8061 #16 0x0843e1e9 in select_union::send_data (this=0xaf74728, values=@0xae800fc) at sql_union.cc:60 #17 0x08309a48 in end_send (join=0xafcc100, join_tab=0xaf5ff0c, end_of_records=false) at sql_select.cc:14406 #18 0x08315b79 in evaluate_join_record (join=0xafcc100, join_tab=0xaf5fd58, error=0) at sql_select.cc:13568 #19 0x08315da5 in sub_select (join=0xafcc100, join_tab=0xaf5fd58, end_of_records=false) at sql_select.cc:13342 #20 0x08322d70 in do_select (join=0xafcc100, fields=0xae800fc, table=0x0, procedure=0x0) at sql_select.cc:13092 #21 0x08335655 in JOIN::exec (this=0xae7edb8) at sql_select.cc:2740 #22 0x083308f2 in mysql_select (thd=0xa9c09c90, rref_pointer_array=0xaf1437c, tables=0xaf73990, wild_num=0, fields=@0xaf1430c, conds=0xaf73ca0, og_num=1, order=0x0, group=0xaf73e38, having=0x0, proc_param=0x0, select_options=2417773056, result=0xaf74728, unit=0xaf14410, select_lex=0xaf14278) at sql_select.cc:2929 #23 0x0843e6f8 in mysql_derived_filling (thd=0xa9c09c90, lex=0xa9c0ad60, orig_table_list=0xaf74138) at sql_derived.cc:264 #24 0x0843e4a3 in mysql_handle_derived (lex=0xa9c0ad60, processor=0x843e528 <mysql_derived_filling(THD*, st_lex*, TABLE_LIST*)>) at sql_derived.cc:56 #25 0x082f890f in open_and_lock_tables_derived (thd=0xa9c09c90, tables=0xaf74138, derived=true) at sql_base.cc:4929 #26 0x082b7921 in open_and_lock_tables (thd=0xa9c09c90, tables=0xaf74138) at mysql_priv.h:1606 #27 0x082aa403 in execute_sqlcom_select (thd=0xa9c09c90, all_tables=0xaf74138) at sql_parse.cc:4789 #28 0x082ac0c9 in mysql_execute_command (thd=0xa9c09c90) at sql_parse.cc:2018 #29 0x082b4ec6 in mysql_parse (thd=0xa9c09c90, inBuf=0xaf13cc0 "EXPLAIN EXTENDED SELECT int_key FROM ( SELECT ( SELECT COUNT( pk ) FROM ( SELECT AVG( int_nokey ) FROM D AS X WHERE X . int_key < 76 ORDER BY int_nokey LIMIT 20 ) AS X WHERE X . int_nokey < 83 GROUP"..., length=317, found_semicolon=0xa9bff260) at sql_parse.cc:5782 #30 0x082b590f in dispatch_command (command=COM_QUERY, thd=0xa9c09c90, packet=0xa9c0b689 "EXPLAIN EXTENDED SELECT int_key FROM ( SELECT ( SELECT COUNT( pk ) FROM ( SELECT AVG( int_nokey ) FROM D AS X WHERE X . int_key < 76 ORDER BY int_nokey LIMIT 20 ) AS X WHERE X . int_nokey < 83 GROUP"..., packet_length=319) at sql_parse.cc:1059 #31 0x082b6b75 in do_command (thd=0xa9c09c90) at sql_parse.cc:732 #32 0x082a4385 in handle_one_connection (arg=0xa9c09c90) at sql_connect.cc:1134 #33 0x0057d32f in start_thread () from /lib/libpthread.so.0 #34 0x0049a27e in clone () from /lib/libc.so.6 The query in question was: EXPLAIN EXTENDED SELECT int_key FROM ( SELECT ( SELECT COUNT( pk ) FROM ( SELECT AVG( int_nokey ) FROM D AS X WHERE X . int_key < 76 ORDER BY int_nokey LIMIT 20 ) AS X WHERE X . int_nokey < 83 GROUP BY int_key LIMIT 1 ) FROM D AS X WHERE X . int_key < 11 GROUP BY int_nokey LIMIT 20 ) AS X WHERE X . int_nokey < 75 How to repeat: A simplifed test case and data will follow shortly.