[MDEV-18117] Crash with Explain extended when using limit rows examined Created: 2019-01-02  Updated: 2019-05-03  Resolved: 2019-05-03

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.4
Fix Version/s: 10.4.5

Type: Bug Priority: Major
Reporter: Varun Gupta (Inactive) Assignee: Varun Gupta (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
PartOf
is part of MDEV-6111 optimizer trace Closed

 Description   

The dataset 

create table t1 (c1 char(2));
 
create table t2 (c2 char(2));
 
insert into t1 values ('bb'), ('cc'), ('aa'), ('dd');
 
insert into t2 values ('bb'), ('cc'), ('dd'), ('ff');
 
 
 
explain extended
 
select * from t1, t2 where c1 = c2 LIMIT ROWS EXAMINED 2;

Another question would be do we want to add ROWS EXAMINED to also show when we print the limit clause during explain exteded.

 Comments   
Comment by Varun Gupta (Inactive) [ 2019-01-02 ]

The stacktrace is

* thread #2, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
 
  * frame #0: 0x0000000100bdfe73 mysqld`st_select_lex::print_limit(this=0x000062b0000a1380, thd=0x000062b00009a270, str=0x000070000eb35000, query_type=QT_EXPLAIN_EXTENDED) at sql_lex.cc:3060
 
    frame #1: 0x0000000100ef388a mysqld`st_select_lex::print(this=0x000062b0000a1380, thd=0x000062b00009a270, str=0x000070000eb35000, query_type=QT_EXPLAIN_EXTENDED) at sql_select.cc:26391
 
    frame #2: 0x0000000100bdf010 mysqld`st_select_lex_unit::print(this=0x000062b00009e160, str=0x000070000eb35000, query_type=QT_EXPLAIN_EXTENDED) at sql_lex.cc:2984
 
    frame #3: 0x0000000100ca7c34 mysqld`execute_sqlcom_select(thd=0x000062b00009a270, all_tables=0x000062b0000a1908) at sql_parse.cc:6533
 
    frame #4: 0x0000000100c835f5 mysqld`mysql_execute_command(thd=0x000062b00009a270) at sql_parse.cc:3776
 
    frame #5: 0x0000000100c7073b mysqld`mysql_parse(thd=0x000062b00009a270, rawbuf="explain extended select * from t1, t2 where c1 = c2 LIMIT ROWS EXAMINED 2", length=73, parser_state=0x000070000eb3cce0, is_com_multi=false, is_next_command=false) at sql_parse.cc:8104
 
    frame #6: 0x0000000100c5e7ff mysqld`dispatch_command(command=COM_QUERY, thd=0x000062b00009a270, packet="", packet_length=73, is_com_multi=false, is_next_command=false) at sql_parse.cc:1850
 
    frame #7: 0x0000000100c69793 mysqld`do_command(thd=0x000062b00009a270) at sql_parse.cc:1395
 
    frame #8: 0x00000001012c1ac7 mysqld`do_handle_one_connection(connect=0x000061100003bbb0) at sql_connect.cc:1402
 
    frame #9: 0x00000001012c106d mysqld`::handle_one_connection(arg=0x000061100003bbb0) at sql_connect.cc:1308
 
    frame #10: 0x00007fff66370339 libsystem_pthread.dylib`_pthread_body + 126
 
    frame #11: 0x00007fff663732a7 libsystem_pthread.dylib`_pthread_start + 70
 
    frame #12: 0x00007fff6636f445 libsystem_pthread.dylib`thread_start + 13

Comment by Varun Gupta (Inactive) [ 2019-01-02 ]

Patch
http://lists.askmonty.org/pipermail/commits/2019-January/013237.html

Comment by Alice Sherepa [ 2019-02-19 ]

Just one more example:

explain extended select var_pop(1) from dual limit rows examined 3;


#4  0x000055f15a6e4862 in st_select_lex::print_limit (this=0x7ff41003a990, thd=0x7ff410000a98, str=0x7ff42c125060, query_type=QT_EXPLAIN_EXTENDED) at /10.4/sql/sql_lex.cc:3061
 
#5  0x000055f15a7a2d6a in st_select_lex::print (this=0x7ff41003a990, thd=0x7ff410000a98, str=0x7ff42c125060, query_type=QT_EXPLAIN_EXTENDED) at /10.4/sql/sql_select.cc:26965
 
#6  0x000055f15a6e44f5 in st_select_lex_unit::print (this=0x7ff4100049a0, str=0x7ff42c125060, query_type=QT_EXPLAIN_EXTENDED) at /10.4/sql/sql_lex.cc:2985
 
#7  0x000055f15a71fbfc in execute_sqlcom_select (thd=0x7ff410000a98, all_tables=0x7ff41016a240) at /10.4/sql/sql_parse.cc:6554
 
#8  0x000055f15a714d51 in mysql_execute_command (thd=0x7ff410000a98) at /10.4/sql/sql_parse.cc:3825
 
#9  0x000055f15a723e09 in mysql_parse (thd=0x7ff410000a98, rawbuf=0x7ff410151550 "EXPLAIN EXTENDED SELECT  VAR_POP((FORMAT(0, 3))) FROM t1 LIMIT ROWS EXAMINED 3", length=78, parser_state=0x7ff42c126060, is_com_multi=false, is_next_command=false) at /10.4/sql/sql_parse.cc:8141
 
#10 0x000055f15a70f0a6 in dispatch_command (command=COM_QUERY, thd=0x7ff410000a98, packet=0x7ff410009ac9 "", packet_length=78, is_com_multi=false, is_next_command=false) at /10.4/sql/sql_parse.cc:1820
 
#11 0x000055f15a70d8f6 in do_command (thd=0x7ff410000a98) at /10.4/sql/sql_parse.cc:1358
 
#12 0x000055f15a888ab3 in do_handle_one_connection (connect=0x55f15e8f5568) at /10.4/sql/sql_connect.cc:1399
 
#13 0x000055f15a8887f1 in handle_one_connection (arg=0x55f15e8f5568) at /10.4/sql/sql_connect.cc:1302
 
#14 0x000055f15b2111a9 in pfs_spawn_thread (arg=0x55f15e8809c8) at /10.4/storage/perfschema/pfs.cc:1862
 
#15 0x00007ff432c9f6ba in start_thread (arg=0x7ff42c127700) at pthread_create.c:333
 
#16 0x00007ff431f3041d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Comment by Igor Babaev [ 2019-05-01 ]

Ok to push into 10.4

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