[MDEV-6223] Assertion `! is_set()' fails in Diagnostics_area::set_eof_status on EXPLAIN INSERT executed as a PS Created: 2014-05-09  Updated: 2015-10-06  Resolved: 2015-10-06

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.0.10
Fix Version/s: 10.0.22

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

Issue Links:
Relates
relates to MDEV-8321 Assertion `! is_set()' failed in Diag... Closed

 Description    

CREATE TABLE t1 (a INT) ENGINE = MyISAM;
 
CREATE TABLE t2 (b INT) ENGINE = MyISAM;
 
INSERT INTO t2 VALUES (1),(2);
 
PREPARE stmt FROM 'EXPLAIN INSERT INTO t1 SELECT * FROM t2';
 
EXECUTE stmt;
 

10.0/sql/sql_error.cc:406: void Diagnostics_area::set_eof_status(THD*): Assertion `! is_set()' failed.
 
140509 20:11:24 [ERROR] mysqld got signal 6 ;
 

#6  0x00007ffce35f2621 in *__GI___assert_fail (assertion=0xf195af "! is_set()", file=<optimized out>, line=406, function=0xf1a100 "void Diagnostics_area::set_eof_status(THD*)") at assert.c:81
 
#7  0x0000000000650390 in Diagnostics_area::set_eof_status (this=0x7ffcd93fa0d0, thd=0x7ffcd93f5070) at 10.0/sql/sql_error.cc:406
 
#8  0x00000000005d34ab in my_eof (thd=0x7ffcd93f5070) at 10.0/sql/sql_class.h:3749
 
#9  0x000000000063b0ab in select_send::send_eof (this=0x7ffccf1a6e78) at 10.0/sql/sql_class.cc:2572
 
#10 0x00000000007bffb9 in Explain_query::send_explain (this=0x7ffccf1a6858, thd=0x7ffcd93f5070) at 10.0/sql/sql_explain.cc:146
 
#11 0x00000000006770e8 in mysql_execute_command (thd=0x7ffcd93f5070) at 10.0/sql/sql_parse.cc:3542
 
#12 0x0000000000697298 in Prepared_statement::execute (this=0x7ffccf1cd470, expanded_query=0x7ffce5574b00, open_cursor=false) at 10.0/sql/sql_prepare.cc:3971
 
#13 0x0000000000696373 in Prepared_statement::execute_loop (this=0x7ffccf1cd470, expanded_query=0x7ffce5574b00, open_cursor=false, packet=0x0, packet_end=0x0) at 10.0/sql/sql_prepare.cc:3626
 
#14 0x0000000000694675 in mysql_sql_stmt_execute (thd=0x7ffcd93f5070) at 10.0/sql/sql_prepare.cc:2777
 
#15 0x00000000006749e1 in mysql_execute_command (thd=0x7ffcd93f5070) at 10.0/sql/sql_parse.cc:2564
 
#16 0x000000000067ed75 in mysql_parse (thd=0x7ffcd93f5070, rawbuf=0x7ffccf1a5088 "EXECUTE stmt", length=12, parser_state=0x7ffce5575610) at 10.0/sql/sql_parse.cc:6410
 
#17 0x0000000000671c54 in dispatch_command (command=COM_QUERY, thd=0x7ffcd93f5070, packet=0x7ffcd9623071 "", packet_length=12) at 10.0/sql/sql_parse.cc:1309
 
#18 0x0000000000670ff6 in do_command (thd=0x7ffcd93f5070) at 10.0/sql/sql_parse.cc:1006
 
#19 0x000000000078c03a in do_handle_one_connection (thd_arg=0x7ffcd93f5070) at 10.0/sql/sql_connect.cc:1379
 
#20 0x000000000078bd8d in handle_one_connection (arg=0x7ffcd93f5070) at 10.0/sql/sql_connect.cc:1293
 
#21 0x0000000000cb5ef4 in pfs_spawn_thread (arg=0x7ffcd9471bd0) at 10.0/storage/perfschema/pfs.cc:1853
 
#22 0x00007ffce51a9b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
 
#23 0x00007ffce36a1a7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Stack trace from:

revision-id: sergii@pisem.net-20140506115756-1q98x2ce75opl05y
 
revno: 4188
 
branch-nick: 10.0

Also reproducible on earlier 10.0 versions.
Could not reproduce with MySQL 5.6.10 and MySQL 5.6.17.



 Comments   
Comment by Sergei Petrunia [ 2015-10-05 ]

Looking at 10.1

The assertion happens here:

  #3  0x00007ffff5f89192 in __GI___assert_fail (assertion=0x555556372e19 "! is_set()", file=0x555556372d40 "/home/psergey/dev-git/10.1-dbg3/sql/sql_error.cc", line=407, function=0x555556373300 "void Diagnostics_area::set_eof_status(THD*)") at assert.c:103
 
  #4  0x0000555555a0e0a8 in Diagnostics_area::set_eof_status (this=0x55555ac78af8, thd=0x55555ac73d50) at /home/psergey/dev-git/10.1-dbg3/sql/sql_error.cc:407
 
  #5  0x0000555555987d17 in my_eof (thd=0x55555ac73d50) at /home/psergey/dev-git/10.1-dbg3/sql/sql_class.h:4049
 
  #6  0x00005555559f7f25 in select_send::send_eof (this=0x7fff50009400) at /home/psergey/dev-git/10.1-dbg3/sql/sql_class.cc:2820
 
  #7  0x0000555555b9bbc8 in Explain_query::send_explain (this=0x7fff50008c40, thd=0x55555ac73d50) at /home/psergey/dev-git/10.1-dbg3/sql/sql_explain.cc:173
 
  #8  0x0000555555a3980f in mysql_execute_command (thd=0x55555ac73d50) at /home/psergey/dev-git/10.1-dbg3/sql/sql_parse.cc:4016
 
  #9  0x0000555555a5dd80 in Prepared_statement::execute (this=0x7fff500062e0, expanded_query=0x7ffff4300550, open_cursor=false) at /home/psergey/dev-git/10.1-dbg3/sql/sql_prepare.cc:4016
 
  #10 0x0000555555a5cc64 in Prepared_statement::execute_loop (this=0x7fff500062e0, expanded_query=0x7ffff4300550, open_cursor=false, packet=0x0, packet_end=0x0) at /home/psergey/dev-git/10.1-dbg3/sql/sql_prepare.cc:3648
 
  #11 0x0000555555a5ad3b in mysql_sql_stmt_execute (thd=0x55555ac73d50) at /home/psergey/dev-git/10.1-dbg3/sql/sql_prepare.cc:2781
 
  #12 0x0000555555a36715 in mysql_execute_command (thd=0x55555ac73d50) at /home/psergey/dev-git/10.1-dbg3/sql/sql_parse.cc:2973
 
  #13 0x0000555555a43b1d in mysql_parse (thd=0x55555ac73d50, rawbuf=0x7fff50007418 "EXECUTE stmt", length=12, parser_state=0x7ffff4301100) at /home/psergey/dev-git/10.1-dbg3/sql/sql_parse.cc:7227

and it crashes because Diagnostics_area is not empty already.
Checking where it got filled:

  Hardware watchpoint 4: *$a
 
  Old value = Diagnostics_area::DA_EMPTY
 
  New value = Diagnostics_area::DA_OK
 
  Diagnostics_area::set_ok_status (this=0x55555ac78af8, affected_rows=2, last_insert_id=0, message=0x7ffff42fefb0 "Records: 2  Duplicates: 0  Warnings: 0") at /home/psergey/dev-git/10.1-dbg3/sql/sql_error.cc:394
 
(gdb) wher
 
  #0  Diagnostics_area::set_ok_status (this=0x55555ac78af8, affected_rows=2, last_insert_id=0, message=0x7ffff42fefb0 "Records: 2  Duplicates: 0  Warnings: 0") at /home/psergey/dev-git/10.1-dbg3/sql/sql_error.cc:394
 
  #1  0x00005555559c860a in my_ok (thd=0x55555ac73d50, affected_rows=2, id=0, message=0x7ffff42fefb0 "Records: 2  Duplicates: 0  Warnings: 0") at /home/psergey/dev-git/10.1-dbg3/sql/sql_class.h:4039
 
  #2  0x0000555555a1cb32 in select_insert::send_ok_packet (this=0x7fff500075b0) at /home/psergey/dev-git/10.1-dbg3/sql/sql_insert.cc:3791
 
  #3  0x0000555555a1cbc4 in select_insert::send_eof (this=0x7fff500075b0) at /home/psergey/dev-git/10.1-dbg3/sql/sql_insert.cc:3800
 
  #4  0x0000555555a9d4fa in do_select (join=0x7fff50007650, fields=0x7fff5000dd90, table=0x0, procedure=0x0) at /home/psergey/dev-git/10.1-dbg3/sql/sql_select.cc:17847
 
  #5  0x0000555555a79579 in JOIN::exec_inner (this=0x7fff50007650) at /home/psergey/dev-git/10.1-dbg3/sql/sql_select.cc:3118
 
  #6  0x0000555555a7673f in JOIN::exec (this=0x7fff50007650) at /home/psergey/dev-git/10.1-dbg3/sql/sql_select.cc:2409
 
  #7  0x0000555555a79e21 in mysql_select (thd=0x55555ac73d50, rref_pointer_array=0x7fff5000def0, tables=0x7fff5000f118, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=3489925888, result=0x7fff500075b0, unit=0x7fff5000d588, select_lex=0x7fff5000dc78) at /home/psergey/dev-git/10.1-dbg3/sql/sql_select.cc:3346
 
  #8  0x0000555555a6fd87 in handle_select (thd=0x55555ac73d50, lex=0x7fff5000d4c0, result=0x7fff500075b0, setup_tables_done_option=1073741824) at /home/psergey/dev-git/10.1-dbg3/sql/sql_select.cc:371
 
  #9  0x0000555555a39714 in mysql_execute_command (thd=0x55555ac73d50) at /home/psergey/dev-git/10.1-dbg3/sql/sql_parse.cc:3996
 
  #10 0x0000555555a5dd80 in Prepared_statement::execute (this=0x7fff500062e0, expanded_query=0x7ffff4300550, open_cursor=false) at /home/psergey/dev-git/10.1-dbg3/sql/sql_prepare.cc:4016
 
  #11 0x0000555555a5cc64 in Prepared_statement::execute_loop (this=0x7fff500062e0, expanded_query=0x7ffff4300550, open_cursor=false, packet=0x0, packet_end=0x0) at /home/psergey/dev-git/10.1-dbg3/sql/sql_prepare.cc:3648
 
  #12 0x0000555555a5ad3b in mysql_sql_stmt_execute (thd=0x55555ac73d50) at /home/psergey/dev-git/10.1-dbg3/sql/sql_prepare.cc:2781
 
  #13 0x0000555555a36715 in mysql_execute_command (thd=0x55555ac73d50) at /home/psergey/dev-git/10.1-dbg3/sql/sql_parse.cc:2973
 
  #14 0x0000555555a43b1d in mysql_parse (thd=0x55555ac73d50, rawbuf=0x7fff50007418 "EXECUTE stmt", length=12, parser_state=0x7ffff4301100) at /home/psergey/dev-git/10.1-dbg3/sql/sql_parse.cc:7227
 
  #15 0x0000555555a32881 in dispatch_command (command=COM_QUERY, thd=0x55555ac73d50, packet=0x55555ac7a521 "EXECUTE stmt", packet_length=12) at /home/psergey/dev-git/10.1-dbg3/sql/sql_parse.cc:1488

Comment by Sergei Petrunia [ 2015-10-05 ]

10.1 has ANALYZE-stmt feature, and it has this piece of code

        if (lex->analyze_stmt)
 
          ((select_result_interceptor*)sel_result)->disable_my_ok_calls();

which is a way to prevent select_insert::send_eof from sending anything to the output.

Comment by Sergei Petrunia [ 2015-10-05 ]

A quick fix for 10.1: 

-        if (lex->analyze_stmt)
 
+        if (lex->analyze_stmt || lex->describe)

and testcases for both this bug and MDEV-8321 start to pass.

Comment by Sergei Petrunia [ 2015-10-05 ]

Looking at what select_insert::send_eof() does, I doubt that all of that should be done for EXPLAIN query (for example, thd->binlog_query() call should not be made, I think).

For ANALYZE statment, it is ok that select_insert::send_eof() does everything what it normally does, except calling my_ok(). For EXPLAIN, it might be a wrong solution.

Comment by Sergei Petrunia [ 2015-10-05 ]

http://lists.askmonty.org/pipermail/commits/2015-October/008485.html

Comment by Sergei Petrunia [ 2015-10-05 ]

The above patch fixes this bug and MDEV-8321.

Comment by Sergei Petrunia [ 2015-10-05 ]

sanja, please review.

Comment by Oleksandr Byelkin [ 2015-10-06 ]

OK to push!

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