[MDEV-5581] Server crashes in in JOIN::prepare on 2nd execution of PS with materialization+semijoin Created: 2014-01-28  Updated: 2014-02-14  Resolved: 2014-02-14

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 5.5.35, 10.0.7, 5.3.13
Fix Version/s: 5.5.36, 10.0.9, 5.3.13

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Sergei Petrunia
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates

 Description    

#3  <signal handler called>
 
#4  0x0000000000697d83 in JOIN::prepare (this=0x7feea6059998, rref_pointer_array=0x7feea61cf2f8, tables_init=0x7feea61cfc58, wild_num=0, conds_init=0x7feea6348d18, og_num=0, order_init=0x0, skip_order_by=false, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x7feea61cf088, unit_arg=0x7feea61cf3e8) at /home/elenst/bzr/10.0/sql/sql_select.cc:768
 
#5  0x00000000008ecbd6 in subselect_single_select_engine::prepare (this=0x7feea63479b8) at /home/elenst/bzr/10.0/sql/item_subselect.cc:3483
 
#6  0x00000000008e38cc in Item_subselect::fix_fields (this=0x7feea6347828, thd_param=0x7feea8f3d070, ref=0x7feea6348180) at /home/elenst/bzr/10.0/sql/item_subselect.cc:257
 
#7  0x00000000008ebed2 in Item_in_subselect::fix_fields (this=0x7feea6347828, thd_arg=0x7feea8f3d070, ref=0x7feea6348180) at /home/elenst/bzr/10.0/sql/item_subselect.cc:3166
 
#8  0x000000000087fea1 in Item_in_optimizer::fix_fields (this=0x7feea63480e8, thd=0x7feea8f3d070, ref=0x7feeb0922700) at /home/elenst/bzr/10.0/sql/item_cmpfunc.cc:1515
 
#9  0x0000000000610738 in setup_tables (thd=0x7feea8f3d070, context=0x7feea61cc880, from_clause=0x7feea61cc9a0, tables=0x7feea61cd6d0, leaves=..., select_insert=false, full_table_list=false) at /home/elenst/bzr/10.0/sql/sql_base.cc:7822
 
#10 0x00000000006108a1 in setup_tables_and_check_access (thd=0x7feea8f3d070, context=0x7feea61cc880, from_clause=0x7feea61cc9a0, tables=0x7feea61cd6d0, leaves=..., select_insert=false, want_access_first=1, want_access=1, full_table_list=false) at /home/elenst/bzr/10.0/sql/sql_base.cc:7876
 
#11 0x0000000000697b89 in JOIN::prepare (this=0x7feea60592e0, rref_pointer_array=0x7feea61ccaa0, tables_init=0x7feea61cd6d0, wild_num=0, conds_init=0x7feea6348de0, og_num=0, order_init=0x0, skip_order_by=false, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x7feea61cc830, unit_arg=0x7feea61cc150) at /home/elenst/bzr/10.0/sql/sql_select.cc:703
 
#12 0x00000000006a0ac5 in mysql_select (thd=0x7feea8f3d070, rref_pointer_array=0x7feea61ccaa0, tables=0x7feea61cd6d0, wild_num=0, fields=..., conds=0x7feea6348de0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2416184064, result=0x7feea63479f8, unit=0x7feea61cc150, select_lex=0x7feea61cc830) at /home/elenst/bzr/10.0/sql/sql_select.cc:3272
 
#13 0x00000000006972a7 in handle_select (thd=0x7feea8f3d070, lex=0x7feea61cc090, result=0x7feea63479f8, setup_tables_done_option=0) at /home/elenst/bzr/10.0/sql/sql_select.cc:372
 
#14 0x000000000066c3a1 in execute_sqlcom_select (thd=0x7feea8f3d070, all_tables=0x7feea61cd6d0) at /home/elenst/bzr/10.0/sql/sql_parse.cc:5250
 
#15 0x0000000000664815 in mysql_execute_command (thd=0x7feea8f3d070) at /home/elenst/bzr/10.0/sql/sql_parse.cc:2571
 
#16 0x0000000000686e10 in Prepared_statement::execute (this=0x7feea613b470, expanded_query=0x7feeb0923b30, open_cursor=false) at /home/elenst/bzr/10.0/sql/sql_prepare.cc:3971
 
#17 0x0000000000685eeb in Prepared_statement::execute_loop (this=0x7feea613b470, expanded_query=0x7feeb0923b30, open_cursor=false, packet=0x0, packet_end=0x0) at /home/elenst/bzr/10.0/sql/sql_prepare.cc:3626
 
#18 0x00000000006841ee in mysql_sql_stmt_execute (thd=0x7feea8f3d070) at /home/elenst/bzr/10.0/sql/sql_prepare.cc:2777
 
#19 0x0000000000664843 in mysql_execute_command (thd=0x7feea8f3d070) at /home/elenst/bzr/10.0/sql/sql_parse.cc:2581
 
#20 0x000000000066eb20 in mysql_parse (thd=0x7feea8f3d070, rawbuf=0x7feea6059088 "EXECUTE stmt", length=12, parser_state=0x7feeb0924630) at /home/elenst/bzr/10.0/sql/sql_parse.cc:6394
 
#21 0x00000000006619da in dispatch_command (command=COM_QUERY, thd=0x7feea8f3d070, packet=0x7feea8f33071 "EXECUTE stmt", packet_length=12) at /home/elenst/bzr/10.0/sql/sql_parse.cc:1296
 
#22 0x0000000000660d7c in do_command (thd=0x7feea8f3d070) at /home/elenst/bzr/10.0/sql/sql_parse.cc:993
 
#23 0x000000000077a4bd in do_handle_one_connection (thd_arg=0x7feea8f3d070) at /home/elenst/bzr/10.0/sql/sql_connect.cc:1379
 
#24 0x000000000077a210 in handle_one_connection (arg=0x7feea8f3d070) at /home/elenst/bzr/10.0/sql/sql_connect.cc:1293
 
#25 0x0000000000a9d1f1 in pfs_spawn_thread (arg=0x7feea9775df0) at /home/elenst/bzr/10.0/storage/perfschema/pfs.cc:1853
 
#26 0x00007feeb0671b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
 
#27 0x00007feeaf1c0a7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
 

revision-id: bar@mnogosearch.org-20140127091540-1ij1ogw9l9v8je7h
 
revno: 3744
 
branch-nick: 5.3
 
BUILD/compile-pentium-debug-max-no-ndb
 

SET optimizer_switch = 'materialization=on,semijoin=on';
 
 
 
CREATE TABLE t1 (a INT);
 
INSERT INTO t1 VALUES (2),(3);
 
 
 
CREATE TABLE t2 (b INT);
 
INSERT INTO t2 VALUES (8),(9);
 
 
 
CREATE TABLE t3 (c INT, INDEX(c));
 
INSERT INTO t2 VALUES (5),(6);
 
 
 
PREPARE stmt FROM "SELECT * FROM t1 WHERE ( 9, 5 ) IN ( SELECT b, COUNT(*) FROM t2 WHERE 1 IN ( SELECT MIN(c) FROM t3 ) )";
 
EXECUTE stmt;
 
EXECUTE stmt;



 Comments   
Comment by Sergei Petrunia [ 2014-02-06 ]

The query plan:

------------------------------------------------------------+

id select_type table type possible_keys key key_len ref rows Extra

------------------------------------------------------------+

1 PRIMARY NULL NULL NULL NULL NULL NULL NULL Impossible WHERE
2 MATERIALIZED NULL NULL NULL NULL NULL NULL NULL Impossible WHERE
3 MATERIALIZED NULL NULL NULL NULL NULL NULL NULL No matching min/max row

------------------------------------------------------------+

Both subqueries are non-merged semi-joins (aka JTBMs). Both are degenerate, i.e. they have no rows in the materialized table.
First EXECUTE creates and frees dummy temporary tables.

The crash happens on the second execute, when we try to run this code:

706 tbl->table->maybe_null= 1;

and the problem is that tbl->table == NULL, the temp.table hasn't been created yet.

Comment by Sergei Petrunia [ 2014-02-08 ]

This bug is not fixed by fix for MDEV-5582.

Comment by Sergei Petrunia [ 2014-02-10 ]

I'm debugging the second EXECUTE.

I see that setup_tables() is invoked and does some processing for TABLE_LISTs
that are non-merged semi-joins (aka JTBMs). However, it doesn't create TABLE
objects for them.

TABLE objects are created in setup_jtbm_semi_joins(), which is called from
parent join's JOIN::optmize().

However, the code in JOIN::prepare()

/*
If the query uses implicit grouping where the select list contains both
aggregate functions and non-aggregate fields, any non-aggregated field
may produce a NULL value. Set all fields of each table as nullable before
semantic analysis to take into account this change of nullability.

Note: this loop doesn't touch tables inside merged semi-joins, because
subquery-to-semijoin conversion has not been done yet. This is intended.
*/
if (mixed_implicit_grouping)
{
tbl->table->maybe_null= 1;

tries to access TABLE* and crashes.

Comment by Sergei Petrunia [ 2014-02-10 ]

Possible solutions:
1. Postpone the action done in JOIN::prepare() until there is a TABLE* object.
For example, remember in TABLE_LIST somewhere that we should set
TABLE::maybe_null to true and do it once we have the TABLE object.

2. Perform the actions of setup_jtbm_semi_joins() earlier, at prepare phase.
Note that we can't call the whole function earlier, because it calls optimize() for the subqueries.

Comment by Sergei Petrunia [ 2014-02-10 ]

Doing #2 is rather difficult, because there are two ways a temporary table is created
C1. subquery is not degenerate, subquery optimization process creates a tmp.table
C2. subquery is degenerate, setup_jtbm_semi_joins() calls create_dummy_tmp_table().

It is possible to factor out temp.table creation code out of C1 and C2, but this is a significant change.

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