[MDEV-6223] Assertion `! is_set()' fails in Diagnostics_area::set_eof_status on EXPLAIN INSERT executed as a PS - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Affects Version/s: 10.0.10
Fix Version/s: 10.0.22
Component/s: Optimizer
Labels:
None

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.

Attachments

Issue Links

relates to

MDEV-8321 Assertion `! is_set()' failed in Diagnostics_area::set_eof_status on EXPLAIN INSERT ... UNION

Closed

Activity

Ascending order - Click to sort in descending order

Elena Stepanova created issue - 2014-05-09 19:14

Sergei Golubchik made changes - 2014-06-13 15:06

Field	Original Value	New Value
Workflow	defaullt [ 40403 ]	MariaDB v2 [ 42529 ]

Sergei Golubchik made changes - 2014-06-16 13:27

Fix Version/s		10.0.13 [ 16000 ]
Fix Version/s	10.0.12 [ 15201 ]

Rasmus Johansson (Inactive) made changes - 2015-05-18 17:50

Workflow

MariaDB v2 [ 42529 ]

MariaDB v3 [ 62200 ]

Elena Stepanova made changes - 2015-06-16 14:50

Link

This issue relates to ~~MDEV-8321~~ [ ~~MDEV-8321~~ ]

Sergei Petrunia added a comment - 2015-10-05 17:21

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

Sergei Petrunia added a comment - 2015-10-05 17:21 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

Sergei Petrunia added a comment - 2015-10-05 17:23

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.

Sergei Petrunia added a comment - 2015-10-05 17:23 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.

Sergei Petrunia added a comment - 2015-10-05 17:42

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.

Sergei Petrunia added a comment - 2015-10-05 17:42 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.

Sergei Petrunia added a comment - 2015-10-05 17:45

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.

Sergei Petrunia added a comment - 2015-10-05 17:45 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.

Sergei Petrunia added a comment - 2015-10-05 20:56

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

Sergei Petrunia added a comment - 2015-10-05 20:56 http://lists.askmonty.org/pipermail/commits/2015-October/008485.html

Sergei Petrunia added a comment - 2015-10-05 20:57

The above patch fixes this bug and ~~MDEV-8321~~.

Sergei Petrunia added a comment - 2015-10-05 20:57 The above patch fixes this bug and MDEV-8321 .

Sergei Petrunia added a comment - 2015-10-05 20:57

sanja, please review.

Sergei Petrunia added a comment - 2015-10-05 20:57 sanja , please review.

Oleksandr Byelkin added a comment - 2015-10-06 14:15 - edited

OK to push!

Oleksandr Byelkin added a comment - 2015-10-06 14:15 - edited OK to push!

Sergei Petrunia made changes - 2015-10-06 16:08

Component/s		Optimizer [ 10200 ]
Fix Version/s		10.0.22 [ 19700 ]
Fix Version/s	10.0 [ 16000 ]
Assignee	Oleksandr Byelkin [ sanja ]	Sergei Petrunia [ psergey ]
Resolution		Fixed [ 1 ]
Status	Open [ 1 ]	Closed [ 6 ]

Sergei Petrunia made changes - 2015-10-06 16:09

Priority

Minor [ 4 ]

Major [ 3 ]

Sergei Golubchik made changes - 2021-12-06 21:40

Workflow

MariaDB v3 [ 62200 ]

MariaDB v4 [ 147877 ]

People

Assignee:: Sergei Petrunia

Reporter:: Elena Stepanova

Votes:: 0 Vote for this issue

Watchers:: 3 Start watching this issue

Dates

Created:: 2014-05-09 19:14

Updated:: 2015-10-06 16:09

Resolved:: 2015-10-06 16:08

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server