[MDEV-7024] Assertion `! is_set()' failed in Diagnostics_area::set_eof_status on executing ANALYZE SELECT via PS Created: 2014-11-05  Updated: 2015-02-02  Resolved: 2015-01-29

Status: Closed
Project: MariaDB Server
Component/s: Prepared Statements
Affects Version/s: 10.1.1
Fix Version/s: 10.1.3

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Oleksandr Byelkin
Resolution: Fixed Votes: 0
Labels: analyze-stmt

Issue Links:
Blocks
blocks MDEV-6422 More testing for ANALYZE stmt and JSON Closed
Relates
relates to MDEV-406 ANALYZE $stmt Closed

 Description   

The problem appeared on 10.1 tree with this revision

 
commit d44dd54bc838e6679f451a8faf07a7f44efe2fa4
 
Author: Sergei Petrunia <psergey@askmonty.org>
 
Date:   Fri Oct 17 14:18:10 2014 +0400
 
 
 
    MDEV-6400: "ANALYZE SELECT ... INTO @var" doesn't set @var
 
    
    Make ANALYZE work for
 
    - ANALYZE SELECT ... INTO @var
 
    - ANALYZE INSERT SELECT ...;
 
    - ANALYZE SELECT .. INTO OUTFILE

Test case

 
prepare stmt from "analyze select * from mysql.user";
 
execute stmt;

Error log

 
10.1/sql/sql_error.cc:406: void Diagnostics_area::set_eof_status(THD*): Assertion `! is_set()' failed.
 
141105 14:27:33 [ERROR] mysqld got signal 6 ;
 

#6  0x00007f459bd6a6f1 in *__GI___assert_fail (assertion=0x7f459ef8b687 "! is_set()", file=<optimized out>, line=406, function=0x7f459ef8c480 "void Diagnostics_area::set_eof_status(THD*)") at assert.c:81
 
#7  0x00007f459e657f28 in Diagnostics_area::set_eof_status (this=0x7f45993fd100, thd=0x7f45993f8070) at 10.1/sql/sql_error.cc:406
 
#8  0x00007f459e5d2da1 in my_eof (thd=0x7f45993f8070) at 10.1/sql/sql_class.h:3849
 
#9  0x00007f459e641be1 in select_send::send_eof (this=0x7f4592900d60) at 10.1/sql/sql_class.cc:2697
 
#10 0x00007f459e7df671 in Explain_query::send_explain (this=0x7f4592900860, thd=0x7f45993f8070) at 10.1/sql/sql_explain.cc:146
 
#11 0x00007f459e688616 in execute_sqlcom_select (thd=0x7f45993f8070, all_tables=0x7f4592b2d698) at 10.1/sql/sql_parse.cc:5692
 
#12 0x00007f459e67eac3 in mysql_execute_command (thd=0x7f45993f8070) at 10.1/sql/sql_parse.cc:2802
 
#13 0x00007f459e6a51b0 in Prepared_statement::execute (this=0x7f4592a39470, expanded_query=0x7f459e14d550, open_cursor=false) at 10.1/sql/sql_prepare.cc:4038
 
#14 0x00007f459e6a3ff9 in Prepared_statement::execute_loop (this=0x7f4592a39470, expanded_query=0x7f459e14d550, open_cursor=false, packet=0x0, packet_end=0x0) at 10.1/sql/sql_prepare.cc:3665
 
#15 0x00007f459e6a2095 in mysql_sql_stmt_execute (thd=0x7f45993f8070) at 10.1/sql/sql_prepare.cc:2801
 
#16 0x00007f459e67eaf4 in mysql_execute_command (thd=0x7f45993f8070) at 10.1/sql/sql_parse.cc:2813
 
#17 0x00007f459e68b681 in mysql_parse (thd=0x7f45993f8070, rawbuf=0x7f45928ff088 "execute stmt", length=12, parser_state=0x7f459e14e1c0) at 10.1/sql/sql_parse.cc:6953
 
#18 0x00007f459e67b741 in dispatch_command (command=COM_QUERY, thd=0x7f45993f8070, packet=0x7f4597bfa071 "", packet_length=12) at 10.1/sql/sql_parse.cc:1466
 
#19 0x00007f459e67a55f in do_command (thd=0x7f45993f8070) at 10.1/sql/sql_parse.cc:1095
 
#20 0x00007f459e7a7f27 in do_handle_one_connection (thd_arg=0x7f45993f8070) at 10.1/sql/sql_connect.cc:1351
 
#21 0x00007f459e7a7c6c in handle_one_connection (arg=0x7f45993f8070) at 10.1/sql/sql_connect.cc:1262
 
#22 0x00007f459ed39f2e in pfs_spawn_thread (arg=0x7f459b4249f0) at 10.1/storage/perfschema/pfs.cc:1860
 
#23 0x00007f459dd84b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
 
#24 0x00007f459be1b20d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Stack trace from

 
commit 43f185e171eecdce41e71c548ce0bc2bd6969c0f
 
Author: Alexander Barkov <bar@mariadb.org>
 
Date:   Mon Nov 3 21:45:06 2014 +0400



 Comments   
Comment by Elena Stepanova [ 2014-11-05 ]

Variation of the stack trace using binary protocol:

#6  0x00007f78f71946f1 in *__GI___assert_fail (assertion=0x7f78fa3b5687 "! is_set()", file=<optimized out>, line=406, function=0x7f78fa3b6480 "void Diagnostics_area::set_eof_status(THD*)") at assert.c:81
 
#7  0x00007f78f9a81f28 in Diagnostics_area::set_eof_status (this=0x7f78dd89d100, thd=0x7f78dd898070) at 10.1/sql/sql_error.cc:406
 
#8  0x00007f78f99fcda1 in my_eof (thd=0x7f78dd898070) at 10.1/sql/sql_class.h:3849
 
#9  0x00007f78f9accb41 in Select_fetch_protocol_binary::send_eof (this=0x7f78d9186528) at 10.1/sql/sql_prepare.cc:3093
 
#10 0x00007f78f9e2bf1d in Materialized_cursor::open (this=0x7f78d916a888, join=0x0) at 10.1/sql/sql_cursor.cc:301
 
#11 0x00007f78f9e2b8e1 in mysql_open_cursor (thd=0x7f78dd898070, result=0x7f78d9186528, pcursor=0x7f78d9186588) at 10.1/sql/sql_cursor.cc:164
 
#12 0x00007f78f9acf0f9 in Prepared_statement::execute (this=0x7f78d9186470, expanded_query=0x7f78f94d6010, open_cursor=true) at 10.1/sql/sql_prepare.cc:4018
 
#13 0x00007f78f9acdff9 in Prepared_statement::execute_loop (this=0x7f78d9186470, expanded_query=0x7f78f94d6010, open_cursor=true, packet=0x7f78dd89e07a "def\004test\001l\020dbmail_partlists\004part\004part\f?", packet_end=0x7f78dd89e07a "def\004test\001l\020dbmail_partlists\004part\004part\f?") at 10.1/sql/sql_prepare.cc:3665
 
#14 0x00007f78f9acbe39 in mysqld_stmt_execute (thd=0x7f78dd898070, packet_arg=0x7f78dd89e071 "", packet_length=9) at 10.1/sql/sql_prepare.cc:2746
 
#15 0x00007f78f9aa5474 in dispatch_command (command=COM_STMT_EXECUTE, thd=0x7f78dd898070, packet=0x7f78dd89e071 "", packet_length=9) at 10.1/sql/sql_parse.cc:1414
 
#16 0x00007f78f9aa455f in do_command (thd=0x7f78dd898070) at 10.1/sql/sql_parse.cc:1095
 
#17 0x00007f78f9bd1f27 in do_handle_one_connection (thd_arg=0x7f78dd898070) at 10.1/sql/sql_connect.cc:1351
 
#18 0x00007f78f9bd1c6c in handle_one_connection (arg=0x7f78dd898070) at 10.1/sql/sql_connect.cc:1262
 
#19 0x00007f78f91aeb50 in start_thread (arg=<optimized out>) at pthread_create.c:304
 
#20 0x00007f78f724520d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Comment by Oleksandr Byelkin [ 2015-01-29 ]

it looks like metadata sent twice (first before optimize, second after execution)

Comment by Oleksandr Byelkin [ 2015-01-29 ]

First it send normal select fields, then ANALYZE fields after execution (which is second result set).

Comment by Oleksandr Byelkin [ 2015-01-29 ]

As expected normal execution do it only once.

Comment by Oleksandr Byelkin [ 2015-01-29 ]

... because select_send_analyze used as select result class...

Comment by Oleksandr Byelkin [ 2015-01-29 ]

select_send::is_result_interceptor() return 1 which is a problem because it return results to client

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