[MDEV-10045] Server crashes in Time_and_counter_tracker::incr_loops Created: 2016-05-09  Updated: 2016-08-29  Resolved: 2016-07-22

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.1, 10.2
Fix Version/s: 10.1.17, 10.2.2

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Oleksandr Byelkin
Resolution: Fixed Votes: 0
Labels: None

Sprint: 10.1.15, 10.2.2-2

 Description    

SET NAMES utf8;
 
 
 
CREATE TABLE t1 (f1 VARCHAR(3), f2 INT UNSIGNED) ENGINE=MyISAM;
 
CREATE TABLE t2 (f3 INT) ENGINE=MyISAM;
 
 
 
SELECT * FROM t1, t2 WHERE f3 = f2 AND f1 > ANY ( SELECT 'foo' UNION SELECT 'bar' );

Stack trace from 10.1 commit 5534d8143004022a8431068b1e1f53bd8d7046e9

 
#3  <signal handler called>
 
#4  0x000055e4705aa9c8 in Time_and_counter_tracker::incr_loops (this=0x78) at /src/10.1/sql/sql_analyze_stmt.h:97
 
#5  0x000055e47056e68f in JOIN::exec (this=0x7f21f5a55dc0) at /src/10.1/sql/sql_select.cc:2516
 
#6  0x000055e4706042c7 in st_select_lex_unit::exec (this=0x7f21f5a53e98) at /src/10.1/sql/sql_union.cc:832
 
#7  0x000055e47081669b in subselect_union_engine::exec (this=0x7f21f5a54f60) at /src/10.1/sql/item_subselect.cc:3785
 
#8  0x000055e47080c9c8 in Item_subselect::exec (this=0x7f21f5a58618) at /src/10.1/sql/item_subselect.cc:684
 
#9  0x000055e47080e468 in Item_singlerow_subselect::val_str (this=0x7f21f5a58618, str=0x7f22016f5aa0) at /src/10.1/sql/item_subselect.cc:1295
 
#10 0x000055e470799b00 in Item_func_conv_charset::Item_func_conv_charset (this=0x7f21f58e92d0, thd=0x7f21fb1c9530, a=0x7f21f5a58618, cs=0x55e4716c58c0 <my_charset_latin1>, cache_if_const=true) at /src/10.1/sql/item_strfunc.h:975
 
#11 0x000055e47077e8f7 in Item::safe_charset_converter (this=0x7f21f5a58618, thd=0x7f21fb1c9530, tocs=0x55e4716c58c0 <my_charset_latin1>) at /src/10.1/sql/item.cc:1084
 
#12 0x000055e47078136f in Item_func_or_sum::agg_item_set_converter (this=0x7f21f58e9058, coll=..., fname=0x55e470f3ffc7 "<", args=0x7f21f58e90e0, nargs=2, flags=7, item_sep=1) at /src/10.1/sql/item.cc:2141
 
#13 0x000055e4707b10f0 in Item_func_or_sum::agg_arg_charsets (this=0x7f21f58e9058, c=..., items=0x7f21f58e90e0, nitems=2, flags=7, item_sep=1) at /src/10.1/sql/item.h:3714
 
#14 0x000055e4707b1138 in Item_func_or_sum::agg_arg_charsets_for_comparison (this=0x7f21f58e9058, c=..., items=0x7f21f58e90e0, nitems=2, item_sep=1) at /src/10.1/sql/item.h:3760
 
#15 0x000055e47079e0f6 in Item_func::setup_args_and_comparator (this=0x7f21f58e9058, thd=0x7f21fb1c9530, cmp=0x7f21f58e9110) at /src/10.1/sql/item_cmpfunc.cc:509
 
#16 0x000055e47079e201 in Item_bool_rowready_func2::fix_length_and_dec (this=0x7f21f58e9058) at /src/10.1/sql/item_cmpfunc.cc:531
 
#17 0x000055e4707ccf52 in Item_func::fix_fields (this=0x7f21f58e9058, thd=0x7f21fb1c9530, ref=0x7f22016f5f00) at /src/10.1/sql/item_func.cc:234
 
#18 0x000055e4708101e7 in Item_allany_subselect::transform_into_max_min (this=0x7f21f5a54d98, join=0x7f21f5a55dc0) at /src/10.1/sql/item_subselect.cc:1969
 
#19 0x000055e4706b1c17 in JOIN::transform_max_min_subquery (this=0x7f21f5a55dc0) at /src/10.1/sql/opt_subselect.cc:901
 
#20 0x000055e47056992e in JOIN::optimize_inner (this=0x7f21f5a55dc0) at /src/10.1/sql/sql_select.cc:1131
 
#21 0x000055e470569570 in JOIN::optimize (this=0x7f21f5a55dc0) at /src/10.1/sql/sql_select.cc:1036
 
#22 0x000055e47051ff3f in st_select_lex::optimize_unflattened_subqueries (this=0x7f21fb1cd648, const_only=false) at /src/10.1/sql/sql_lex.cc:3760
 
#23 0x000055e4706bbb7a in JOIN::optimize_unflattened_subqueries (this=0x7f21f5a55298) at /src/10.1/sql/opt_subselect.cc:5051
 
#24 0x000055e47056cd73 in JOIN::optimize_inner (this=0x7f21f5a55298) at /src/10.1/sql/sql_select.cc:2043
 
#25 0x000055e470569570 in JOIN::optimize (this=0x7f21f5a55298) at /src/10.1/sql/sql_select.cc:1036
 
#26 0x000055e470571c05 in mysql_select (thd=0x7f21fb1c9530, rref_pointer_array=0x7f21fb1cd8c0, tables=0x7f21f5a52aa0, wild_num=1, fields=..., conds=0x7f21f5a55070, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7f21f5a55278, unit=0x7f21fb1ccf48, select_lex=0x7f21fb1cd648) at /src/10.1/sql/sql_select.cc:3437
 
#27 0x000055e47056773d in handle_select (thd=0x7f21fb1c9530, lex=0x7f21fb1cce80, result=0x7f21f5a55278, setup_tables_done_option=0) at /src/10.1/sql/sql_select.cc:384
 
#28 0x000055e47053798c in execute_sqlcom_select (thd=0x7f21fb1c9530, all_tables=0x7f21f5a52aa0) at /src/10.1/sql/sql_parse.cc:5894
 
#29 0x000055e47052d876 in mysql_execute_command (thd=0x7f21fb1c9530) at /src/10.1/sql/sql_parse.cc:2960
 
#30 0x000055e47053b0a4 in mysql_parse (thd=0x7f21fb1c9530, rawbuf=0x7f21f5a52848 "SELECT * FROM t1, t2 WHERE f3 = f2 AND f1 > ANY ( SELECT 'foo' UNION SELECT 'bar' )", length=83, parser_state=0x7f22016f75e0) at /src/10.1/sql/sql_parse.cc:7314
 
#31 0x000055e470529add in dispatch_command (command=COM_QUERY, thd=0x7f21fb1c9530, packet=0x7f21fa3c9a31 "SELECT * FROM t1, t2 WHERE f3 = f2 AND f1 > ANY ( SELECT 'foo' UNION SELECT 'bar' )", packet_length=83) at /src/10.1/sql/sql_parse.cc:1486
 
#32 0x000055e47052880f in do_command (thd=0x7f21fb1c9530) at /src/10.1/sql/sql_parse.cc:1107
 
#33 0x000055e47065e743 in do_handle_one_connection (thd_arg=0x7f21fb1c9530) at /src/10.1/sql/sql_connect.cc:1350
 
#34 0x000055e47065e4a7 in handle_one_connection (arg=0x7f21fb1c9530) at /src/10.1/sql/sql_connect.cc:1262
 
#35 0x000055e470d68598 in pfs_spawn_thread (arg=0x7f21f9db0bf0) at /src/10.1/storage/perfschema/pfs.cc:1860
 
#36 0x00007f22013720a4 in start_thread () from /lib64/libpthread.so.0
 
#37 0x00007f21ff4e004d in clone () from /lib64/libc.so.6

Reproducible on older 10.1 releases.
Not reproducible on 10.0.

 Comments   
Comment by Oleksandr Byelkin [ 2016-06-22 ]

His is only attempt to evaluate the subquery in the process of its optimization, but mine is not preventing this.

Comment by Oleksandr Byelkin [ 2016-06-22 ]

revision-id: 773ce408762b5f8256d4053b6d0d418d15657b92 (mariadb-10.1.14-24-g773ce40)
parent(s): 63120090f994cc78876944e9f7a76f53337fa46e
committer: Oleksandr Byelkin
timestamp: 2016-06-22 11:17:44 +0200
message:

MDEV-10045: Server crashes in Time_and_counter_tracker::incr_loops

Do not set 'optimized' flag until whole optimization procedure is finished.

—

Comment by Sergei Petrunia [ 2016-06-24 ]

Review feedback provded over email

Comment by Oleksandr Byelkin [ 2016-06-27 ]

revision-id: 0f3aaf1439a22ff5e4db5374b2eefe702e1b246c (mariadb-10.1.14-27-g0f3aaf1)
parent(s): 6f6692008617d789b581971541dd9a1377c8dc5c
committer: Oleksandr Byelkin
timestamp: 2016-06-27 16:43:26 +0200
message:

MDEV-10045: Server crashes in Time_and_counter_tracker::incr_loops

Do not set 'optimized' flag until whole optimization procedure is finished.

—

Comment by Sergei Petrunia [ 2016-07-21 ]

Review feedback provided over email

Comment by Oleksandr Byelkin [ 2016-07-22 ]

revision-id: a52d3aa831454aa2e7dd4dfde9c65d4b87532caa (mariadb-10.1.16-4-ga52d3aa)
parent(s): e6a64e8f0ea36f12bd24ba906aa1f4e2e367a8e0
committer: Oleksandr Byelkin
timestamp: 2016-07-22 17:35:39 +0200
message:

MDEV-10045: Server crashes in Time_and_counter_tracker::incr_loops

Do not set 'optimized' flag until whole optimization procedure is finished.

—

Comment by Elena Stepanova [ 2016-08-14 ]

Somehow this patch also fixed some wrong results, e.g. for a query like that:

CREATE TABLE t1 (i INT) ENGINE=MyISAM;
 
INSERT INTO t1 VALUES (1);
 
SELECT * FROM t1 WHERE i <= SOME ( SELECT 7  UNION SELECT 8 );

Before the fix, it would return an empty set; after the fix, it returns the row as it should.

I'm glad it's fixed, but I'm wondering if it's an expected change. If not, there can be negative sides of it as well.

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