[MDEV-5353] server crash on subselect if WHERE applied to some result field Created: 2013-11-27  Updated: 2014-01-29  Resolved: 2013-12-06

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 5.3.12, 5.5.34, 10.0.6
Fix Version/s: 5.5.35, 10.0.7, 5.3.13

Type: Bug Priority: Major
Reporter: Dmitry Bakshaev Assignee: Oleksandr Byelkin
Resolution: Fixed Votes: 0
Labels: None
Environment:

gentoo linux x86_64


 Description   

executing query:

SELECT * FROM 
( SELECT 100 a, subsel.b FROM ( SELECT 200 b ) subsel ) tmp
 
WHERE tmp.b;

shows correct result:

a       b
 
100     200

but server crashed after query:

SELECT * FROM 
( SELECT 100 a, subsel.b FROM ( SELECT 200 b ) subsel ) tmp
 
WHERE tmp.a;

server log:

Server version: 10.0.6-MariaDB
 
key_buffer_size=134217728
 
read_buffer_size=131072
 
max_used_connections=1
 
max_threads=153
 
thread_count=1
 
It is possible that mysqld could use up to
 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467125 K  bytes of memory
 
Hope that's ok; if not, decrease some variables in the equation.
 
 
 
Thread pointer: 0x0x7fc533f28008
 
Attempting backtrace. You can use the following information to find out
 
where mysqld died. If you see no messages after this, something went
 
terribly wrong...
 
stack_bottom = 0x7fc559b58e48 thread_stack 0x48000
 
??:0(??)[0xa44d1c]
 
??:0(??)[0x6d2f97]
 
??:0(??)[0x7fc559579110]
 
??:0(??)[0x6419a1]
 
??:0(??)[0x6ef7d1]
 
??:0(??)[0x6f2492]
 
??:0(??)[0x6f6035]
 
??:0(??)[0x71d9b5]
 
??:0(??)[0x5e42c6]
 
??:0(??)[0x5e4669]
 
??:0(??)[0x5f77b9]
 
??:0(??)[0x5f9e73]
 
??:0(??)[0x5fc474]
 
??:0(??)[0x5fd187]
 
??:0(??)[0x5af5b6]
 
??:0(??)[0x5b9720]
 
??:0(??)[0x5bc119]
 
??:0(??)[0x5bd7b9]
 
??:0(??)[0x65dc1a]
 
??:0(??)[0x65dc83]
 
??:0(??)[0x86bec7]
 
??:0(??)[0x7fc559571bbe]
 
??:0(??)[0x7fc55804ac9d]
 
 
 
Trying to get some variables.
 
Some pointers may be invalid and cause the dump to abort.
 
Query (0x7fc52d82a020): is an invalid pointer
 
Connection ID (thread ID): 2
 
Status: NOT_KILLED
 
 
 
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=of
 
f,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization
 
=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_so
 
rt_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_b
 
uffer_size=off,table_elimination=on,extended_keys=off,exists_to_in=off



 Comments   
Comment by Elena Stepanova [ 2013-11-27 ]

Thanks for reporting this. As a workaround, you could try to set
optimizer_switch='derived_merge=off'

===========================

SELECT * FROM ( SELECT 100 a, subsel.b FROM ( SELECT 200 b ) subsel ) tmp WHERE tmp.a;

Stack trace from 5.3 revno 3727:

#3 <signal handler called>
#4 0x00000000007211ee in TABLE_LIST::get_real_join_table (this=0x3228ce8) at table.cc:4494
#5 0x00000000005bf2a3 in Item_direct_view_ref::check_null_ref (this=0x322bae0) at item.h:2970
#6 0x00000000005bf520 in Item_direct_view_ref::val_int (this=0x322bae0) at item.h:3033
#7 0x00000000005f04ff in Arg_comparator::compare_int_signed (this=0x32292a0) at item_cmpfunc.cc:1168
#8 0x00000000005d05f0 in Arg_comparator::compare (this=0x32292a0) at item_cmpfunc.h:72
#9 0x00000000005f25d0 in Item_func_ne::val_int (this=0x32291e0) at item_cmpfunc.cc:1884
#10 0x00000000005d24a7 in eval_const_cond (cond=0x32291e0) at item_func.cc:63
#11 0x000000000074968f in remove_eq_conds (thd=0x321dda8, cond=0x32291e0, cond_value=0x32296d0) at sql_select.cc:13714
#12 0x0000000000748435 in optimize_cond (join=0x32293e0, conds=0x32291e0, join_list=0x32209b0, ignore_on_conds=false, cond_value=0x32296d0, cond_equal=0x32297f8) at sql_select.cc:13237
#13 0x00000000007282ee in JOIN::optimize (this=0x32293e0) at sql_select.cc:1028
#14 0x000000000072f4b7 in mysql_select (thd=0x321dda8, rref_pointer_array=0x3220a98, tables=0x3228ce8, wild_num=1, fields=..., conds=0x32291e0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147764736, result=0x3216c80, unit=0x3220338, select_lex=0x3220840) at sql_select.cc:2995
#15 0x0000000000725fad in handle_select (thd=0x321dda8, lex=0x3220298, result=0x3216c80, setup_tables_done_option=0) at sql_select.cc:288
#16 0x00000000006b4ca8 in execute_sqlcom_select (thd=0x321dda8, all_tables=0x3228ce8) at sql_parse.cc:5172
#17 0x00000000006abe44 in mysql_execute_command (thd=0x321dda8) at sql_parse.cc:2305
#18 0x00000000006b760f in mysql_parse (thd=0x321dda8, rawbuf=0x3214cc0 "SELECT * FROM ( SELECT 100 a, subsel.b FROM ( SELECT 200 b ) subsel ) tmp WHERE tmp.a", length=86, found_semicolon=0x7f8c04b8ccb8) at sql_parse.cc:6173
#19 0x00000000006a9624 in dispatch_command (command=COM_QUERY, thd=0x321dda8, packet=0x3210c69 "SELECT * FROM ( SELECT 100 a, subsel.b FROM ( SELECT 200 b ) subsel ) tmp WHERE tmp.a", packet_length=86) at sql_parse.cc:1243
#20 0x00000000006a8910 in do_command (thd=0x321dda8) at sql_parse.cc:923
#21 0x00000000006a5799 in handle_one_connection (arg=0x321dda8) at sql_connect.cc:1231
#22 0x00007f8c03d3eb50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#23 0x00007f8c030e1a7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Comment by Oleksandr Byelkin [ 2013-12-04 ]

Committed for review.

Comment by Oleksandr Byelkin [ 2013-12-05 ]

pushed to 5.3

Comment by Daniel Bartholomew [ 2014-01-29 ]

http://bazaar.launchpad.net/~maria-captains/maria/5.5/revision/2502.567.176

Generated at Thu Feb 08 07:03:37 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.