Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2(EOL)
-
None
Description
|
Stack trace from 10.2 addb38f47 |
#3 <signal handler called>
|
#4 0x00007fdfc25e501a in st_select_lex::set_explain_type (this=0x7fdfb6d23d90, on_the_fly=true) at /data/src/10.2/sql/sql_lex.cc:4380
|
#5 0x00007fdfc266a4ff in JOIN::save_explain_data_intern (this=0x7fdfb6de0518, output=0x7fdfb6de7460, need_tmp_table_arg=false, need_order_arg=false, distinct_arg=false, message=0x7fdfc2f280a0 "no matching row in const table") at /data/src/10.2/sql/sql_select.cc:24428
|
#6 0x00007fdfc26355b7 in JOIN::save_explain_data (this=0x7fdfb6de0518, output=0x7fdfb6de7460, can_overwrite=false, need_tmp_table=false, need_order=false, distinct=false) at /data/src/10.2/sql/sql_select.cc:3118
|
#7 0x00007fdfc262e603 in JOIN::optimize (this=0x7fdfb6de0518) at /data/src/10.2/sql/sql_select.cc:1095
|
#8 0x00007fdfc26cb57c in st_select_lex_unit::optimize (this=0x7fdfb6c55ae8) at /data/src/10.2/sql/sql_union.cc:901
|
#9 0x00007fdfc26cb77b in st_select_lex_unit::exec (this=0x7fdfb6c55ae8) at /data/src/10.2/sql/sql_union.cc:934
|
#10 0x00007fdfc26c8800 in mysql_union (thd=0x7fdfb6c52070, lex=0x7fdfb6c55a20, result=0x7fdfb6d27048, unit=0x7fdfb6c55ae8, setup_tables_done_option=0) at /data/src/10.2/sql/sql_union.cc:41
|
#11 0x00007fdfc262bfb3 in handle_select (thd=0x7fdfb6c52070, lex=0x7fdfb6c55a20, result=0x7fdfb6d27048, setup_tables_done_option=0) at /data/src/10.2/sql/sql_select.cc:351
|
#12 0x00007fdfc25fbc1d in execute_sqlcom_select (thd=0x7fdfb6c52070, all_tables=0x7fdfb6d21388) at /data/src/10.2/sql/sql_parse.cc:6333
|
#13 0x00007fdfc25f1a53 in mysql_execute_command (thd=0x7fdfb6c52070) at /data/src/10.2/sql/sql_parse.cc:3364
|
#14 0x00007fdfc25ff3d7 in mysql_parse (thd=0x7fdfb6c52070, rawbuf=0x7fdfb6d21088 "SELECT * FROM t1, t2 WHERE a2 = i1 and b2 >= i1 AND i1 IN ( SELECT i3 FROM t3 )\nUNION\nSELECT * FROM t1, t2 WHERE a2 = i1 and b2 >= i1 AND i1 IN ( SELECT i3 FROM t3 )", length=165, parser_state=0x7fdfc3571dd0, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7765
|
#15 0x00007fdfc25ed7aa in dispatch_command (command=COM_QUERY, thd=0x7fdfb6c52070, packet=0x7fdfb6d15071 "SELECT * FROM t1, t2 WHERE a2 = i1 and b2 >= i1 AND i1 IN ( SELECT i3 FROM t3 )\nUNION\nSELECT * FROM t1, t2 WHERE a2 = i1 and b2 >= i1 AND i1 IN ( SELECT i3 FROM t3 )\n", packet_length=166, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1793
|
#16 0x00007fdfc25ec1db in do_command (thd=0x7fdfb6c52070) at /data/src/10.2/sql/sql_parse.cc:1353
|
#17 0x00007fdfc2726870 in do_handle_one_connection (connect=0x7fdfbf46d410) at /data/src/10.2/sql/sql_connect.cc:1354
|
#18 0x00007fdfc27265fd in handle_one_connection (arg=0x7fdfbf46d410) at /data/src/10.2/sql/sql_connect.cc:1260
|
#19 0x00007fdfc2a1b63c in pfs_spawn_thread (arg=0x7fdfbf4519f0) at /data/src/10.2/storage/perfschema/pfs.cc:1862
|
#20 0x00007fdfc1cad0a4 in start_thread (arg=0x7fdfc3573300) at pthread_create.c:309
|
#21 0x00007fdfbfe6587d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
|
CREATE TABLE t1 (i1 INT, KEY(i1)) ENGINE=MyISAM; |
INSERT INTO t1 VALUES (4),(8); |
|
CREATE TABLE t2 (a2 INT, b2 INT, KEY(b2)) ENGINE=MyISAM; |
INSERT INTO t2 VALUES (8,7); |
|
CREATE TABLE t3 (i3 INT) ENGINE=MyISAM; |
INSERT INTO t3 VALUES (2),(6); |
|
|
SELECT * FROM t1, t2 WHERE a2 = i1 and b2 >= i1 AND i1 IN ( SELECT i3 FROM t3 ) |
UNION
|
SELECT * FROM t1, t2 WHERE a2 = i1 and b2 >= i1 AND i1 IN ( SELECT i3 FROM t3 ) |
;
|
The problem appeared in 10.2 tree with this revision:
commit a2f245e49f8747f9fd202cae451861a8371e6151
|
Author: Sergei Petrunia <psergey@askmonty.org>
|
Date: Mon Aug 8 23:02:52 2016 +0300
|
|
|
MDEV-10372: EXPLAIN fixes for recursive CTEs, including FORMAT=JSON
|
|
- Tabular EXPLAIN now prints "RECURSIVE UNION".
|
- There is a basic implementation of EXPLAIN FORMAT=JSON.
|
- it produces "recursive_union" JSON struct
|
- No other details or ANALYZE support, yet.
|
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
When I apply the patch for MDEV-10419 (manually), I start to get a different kind of crash:
(gdb) wher
|
#0 0x0000555555a897b5 in st_select_lex::set_explain_type (this=0x7fff5c015d90, on_the_fly=true) at /home/psergey/dev-git/10.2/sql/sql_lex.cc:4380
|
#1 0x0000555555b0dae5 in JOIN::save_explain_data_intern (this=0x7fff5c01a5c0, output=0x7fff5c0204b8, need_tmp_table_arg=false, need_order_arg=false, distinct_arg=false, message=0x5555564076a0 "no matching row in const table") at /home/psergey/dev-git/10.2/sql/sql_select.cc:24428
|
#2 0x0000555555ad9f2b in JOIN::save_explain_data (this=0x7fff5c01a5c0, output=0x7fff5c0204b8, can_overwrite=false, need_tmp_table=false, need_order=false, distinct=false) at /home/psergey/dev-git/10.2/sql/sql_select.cc:3118
|
#3 0x0000555555ad3049 in JOIN::optimize (this=0x7fff5c01a5c0) at /home/psergey/dev-git/10.2/sql/sql_select.cc:1095
|
#4 0x0000555555b6dd0e in st_select_lex_unit::optimize (this=0x7fff5c004578) at /home/psergey/dev-git/10.2/sql/sql_union.cc:901
|
#5 0x0000555555b6df0b in st_select_lex_unit::exec (this=0x7fff5c004578) at /home/psergey/dev-git/10.2/sql/sql_union.cc:934
|
#6 0x0000555555b6afc3 in mysql_union (thd=0x7fff5c000b00, lex=0x7fff5c0044b0, result=0x7fff5c019048, unit=0x7fff5c004578, setup_tables_done_option=0) at /home/psergey/dev-git/10.2/sql/sql_union.cc:41
|
#7 0x0000555555ad09f4 in handle_select (thd=0x7fff5c000b00, lex=0x7fff5c0044b0, result=0x7fff5c019048, setup_tables_done_option=0) at /home/psergey/dev-git/10.2/sql/sql_select.cc:351
|
#8 0x0000555555aa0825 in execute_sqlcom_select (thd=0x7fff5c000b00, all_tables=0x7fff5c013388) at /home/psergey/dev-git/10.2/sql/sql_parse.cc:6333
|
#9 0x0000555555a96400 in mysql_execute_command (thd=0x7fff5c000b00) at /home/psergey/dev-git/10.2/sql/sql_parse.cc:3364
|
#10 0x0000555555aa3fd6 in mysql_parse (thd=0x7fff5c000b00, rawbuf=0x7fff5c013088 "SELECT * FROM t1, t2 WHERE a2 = i1 and b2 >= i1 AND i1 IN ( SELECT i3 FROM t3 ) UNION SELECT * FROM t1, t2 WHERE a2 = i1 and b2 >= i1 AND i1 IN ( SELECT i3 FROM t3 )", length=165, parser_state=0x7ffff42ffca0, is_com_multi=false, is_next_command=false) at /home/psergey/dev-git/10.2/sql/sql_parse.cc:7765
|
(gdb) list
|
4375 {
|
4376 bool uses_cte= false;
|
4377 for (JOIN_TAB *tab= first_explain_order_tab(join); tab;
|
4378 tab= next_explain_order_tab(join, tab))
|
4379 {
|
4380 if (tab->table->pos_in_table_list->with)
|
4381 {
|
4382 uses_cte= true;
|
4383 break;
|
4384 }
|
(gdb) p tab->table
|
$40 = (TABLE *) 0x0
|
(gdb) p tab->is_sjm_nest()
|
$42 = true
|
Patch for MDEV-10419:
https://github.com/MariaDB/server/commit/5fdb3cfcd432b85dc305a1a61c2d018a798a6ac
Fix for the bug:
diff --git a/sql/sql_lex.cc b/sql/sql_lex.cc
|
index 08b6196..7daf78b 100644
|
--- a/sql/sql_lex.cc
|
+++ b/sql/sql_lex.cc
|
@@ -4377,7 +4377,7 @@ void st_select_lex::set_explain_type(bool on_the_fly)
|
for (JOIN_TAB *tab= first_explain_order_tab(join); tab;
|
tab= next_explain_order_tab(join, tab))
|
{
|
- if (tab->table->pos_in_table_list->with)
|
+ if (tab->table && tab->table->pos_in_table_list->with)
|
{
|
uses_cte= true;
|
break;
|
I'll wait for serg to merge the fix for MDEV-10419, then will push this fix
In most recent 10.2 (addb38f4763faa0378cd369106372a0eb0f0ee75), I am getting a different stacktrace.
Note the thd=0xa5a5a5a5a5a5
Program received signal SIGSEGV, Segmentation fault.[Switching to Thread 0x7ffff4301300 (LWP 16797)]0x00005555559e1c94 in Query_arena::alloc (this=0xa5a5a5a5a5a5a5bd, size=8) at /home/psergey/dev-git/10.2/sql/sql_class.h:955(gdb) wher#1 0x0000555555b0eaf0 in print_join (thd=0xa5a5a5a5a5a5a5a5, eliminated_tables=0, str=0x7ffff42fe2c0, tables=0x7fff50012830, query_type=QT_ORDINARY) at /home/psergey/dev-git/10.2/sql/sql_select.cc:24795#2 0x0000555555b0f9e9 in st_select_lex::print (this=0x7fff500126b8, thd=0xa5a5a5a5a5a5a5a5, str=0x7ffff42fe2c0, query_type=QT_ORDINARY) at /home/psergey/dev-git/10.2/sql/sql_select.cc:25100#3 0x0000555555d9383e in subselect_single_select_engine::print (this=0x7fff50013af0, str=0x7ffff42fe2c0, query_type=QT_ORDINARY) at /home/psergey/dev-git/10.2/sql/item_subselect.cc:4271#4 0x0000555555d8980e in Item_subselect::print (this=0x7fff500138f8, str=0x7ffff42fe2c0, query_type=QT_ORDINARY) at /home/psergey/dev-git/10.2/sql/item_subselect.cc:941#5 0x0000555555d90c7e in Item_in_subselect::print (this=0x7fff500138f8, str=0x7ffff42fe2c0, query_type=QT_ORDINARY) at /home/psergey/dev-git/10.2/sql/item_subselect.cc:3167#6 0x0000555555d28aac in Item_cond::print (this=0x7fff50012488, str=0x7ffff42fe2c0, query_type=QT_ORDINARY) at /home/psergey/dev-git/10.2/sql/item_cmpfunc.cc:4836#7 0x0000555555b60900 in print_where (cond=0x7fff50012488, info=0x5555563ee09c "WHERE in setup_conds", query_type=QT_ORDINARY) at /home/psergey/dev-git/10.2/sql/sql_test.cc:67#8 0x0000555555a3a45b in setup_conds (thd=0x7fff50000b00, tables=0x7fff50011138, leaves=..., conds=0x7fff50084098) at /home/psergey/dev-git/10.2/sql/sql_base.cc:7686#9 0x0000555555ad1373 in setup_without_group (thd=0x7fff50000b00, ref_pointer_array=..., tables=0x7fff50011138, leaves=..., fields=..., all_fields=..., conds=0x7fff50084098, order=0x0, group=0x0, win_specs=..., win_funcs=..., hidden_group_fields=0x7fff50083f77, reserved=0x7fff50004f4c) at /home/psergey/dev-git/10.2/sql/sql_select.cc:637#10 0x0000555555ad1dd0 in JOIN::prepare (this=0x7fff50083ca0, tables_init=0x7fff50011138, wild_num=1, conds_init=0x7fff50012488, og_num=0, order_init=0x0, skip_order_by=true, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x7fff50004cb0, unit_arg=0x7fff50004578) at /home/psergey/dev-git/10.2/sql/sql_select.cc:812#11 0x0000555555b6c924 in st_select_lex_unit::prepare (this=0x7fff50004578, thd_arg=0x7fff50000b00, sel_result=0x7fff50016df8, additional_options=268435456) at /home/psergey/dev-git/10.2/sql/sql_union.cc:570This looks like a bug in
MDEV-10419(which is pushed into 5.5 and 10.0, but not to 10.1 or 10.2, yet).