[MDEV-9489] Assertion `0' failed in Protocol::end_statement() on UNION ALL Created: 2016-01-29  Updated: 2016-02-21  Resolved: 2016-02-21

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Subquery
Affects Version/s: 10.1
Fix Version/s: 10.1.12

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Oleksandr Byelkin
Resolution: Fixed Votes: 0
Labels: None

Sprint: 10.1.12

 Description    

CREATE TABLE t1 (f1 INT);
 
CREATE TABLE t2 (f2 INT);
 
INSERT INTO t1 VALUES (1),(2);
 
 
 
( SELECT 1 FROM t1 WHERE f1 NOT IN ( SELECT f2 FROM t2 ) LIMIT 0 )
 
UNION ALL
 
( SELECT 1 FROM t1 WHERE f1 NOT IN ( SELECT f2 FROM t2 ) )
 
;

Stack trace from 10.1 commit 7b14ba63f22e6c98c1982dae8847035ad1b8e155

 
mysqld: /src/10.1/sql/protocol.cc:523: void Protocol::end_statement(): Assertion `0' failed.
 
160129 13:37:25 [ERROR] mysqld got signal 6 ;
 
 
 
#6  0x00007fb70bebe126 in __assert_fail_base () from /lib64/libc.so.6
 
#7  0x00007fb70bebe1d2 in __assert_fail () from /lib64/libc.so.6
 
#8  0x0000559da958109e in Protocol::end_statement (this=0x7fb707dc9ec0) at /src/10.1/sql/protocol.cc:523
 
#9  0x0000559da9635a35 in dispatch_command (command=COM_QUERY, thd=0x7fb707dc9930, packet=0x7fb706fc92b1 "", packet_length=136) at /src/10.1/sql/sql_parse.cc:1941
 
#10 0x0000559da96331a6 in do_command (thd=0x7fb707dc9930) at /src/10.1/sql/sql_parse.cc:1109
 
#11 0x0000559da9768798 in do_handle_one_connection (thd_arg=0x7fb707dc9930) at /src/10.1/sql/sql_connect.cc:1349
 
#12 0x0000559da97684fc in handle_one_connection (arg=0x7fb707dc9930) at /src/10.1/sql/sql_connect.cc:1261
 
#13 0x0000559da9e6ebf2 in pfs_spawn_thread (arg=0x7fb7069b0e70) at /src/10.1/storage/perfschema/pfs.cc:1860
 
#14 0x00007fb70de070a4 in start_thread () from /lib64/libpthread.so.0
 
#15 0x00007fb70bf7504d in clone () from /lib64/libc.so.6



 Comments   
Comment by Elena Stepanova [ 2016-01-30 ]

I'm setting it to critical because the behavior on a release build is really bad. When the same set of queries is executed from a client connection, it hangs. The server remains responsive. You can connect to it, run for example show processlist, but it does not show any activity for the hanging connection, like this (connection 19 is one that is hanging on the query):

ariaDB [test]> show processlist;
 
+----+------+-----------------+------+---------+------+-------+------------------+----------+
 
| Id | User | Host            | db   | Command | Time | State | Info             | Progress |
 
+----+------+-----------------+------+---------+------+-------+------------------+----------+
 
| 19 | root | localhost:44506 | test | Sleep   |    9 |       | NULL             |    0.000 |
 
| 20 | root | localhost:44507 | test | Query   |    0 | init  | show processlist |    0.000 |
 
+----+------+-----------------+------+---------+------+-------+------------------+----------+
 
2 rows in set (0.00 sec)

KILL QUERY does not work:

MariaDB [test]> kill query 19;
 
Query OK, 0 rows affected (0.00 sec)
 
 
 
MariaDB [test]> show processlist;
 
+----+------+-----------------+------+---------+------+-------+------------------+----------+
 
| Id | User | Host            | db   | Command | Time | State | Info             | Progress |
 
+----+------+-----------------+------+---------+------+-------+------------------+----------+
 
| 19 | root | localhost:44506 | test | Killed  |  204 |       | NULL             |    0.000 |
 
| 21 | root | localhost:44525 | test | Query   |    0 | init  | show processlist |    0.000 |
 
+----+------+-----------------+------+---------+------+-------+------------------+----------+
 
2 rows in set (0.00 sec)

Killing the thread works. However, it's nearly impossible for a user to analyze, we will be getting weird complaints about "something hangs", or "something extremely slow", etc. Maybe we already got them, but did not recognize because of the vagueness of the problem. It needs to be fixed asap.

Comment by Oleksandr Byelkin [ 2016-01-31 ]

I checked, it looks like sending OK skipped.

Comment by Oleksandr Byelkin [ 2016-02-18 ]

It is important for reproducing to have materialized IN in the second query:

CREATE TABLE t1 (f1 INT);
 
CREATE TABLE t2 (f2 INT);
 
INSERT INTO t1 VALUES (1),(2);
 
 
 
( SELECT 1 FROM t1 )
 
UNION ALL
 
( SELECT 1 FROM t1 WHERE f1 NOT IN ( SELECT f2 FROM t2 ) )
 
;
 
 
 
drop table t1,t2;

Comment by Oleksandr Byelkin [ 2016-02-18 ]

The problem is that in the time of execution select_union_direct::send_eof() current SELECT_LEX is not the last select of the union of UNION, we send_eof is not send.

JOIN of last select points to the other SELECT_LEX (probably it is the result of materialization)

Comment by Oleksandr Byelkin [ 2016-02-18 ]

revision-id: 1de168b7f354adfb5e2ee07af20b20f7e4ae9075 (mariadb-10.1.11-14-g1de168b)
parent(s): 36ca65b73bcd0152680c88e09558bbe1237577ee
committer: Oleksandr Byelkin
timestamp: 2016-02-18 17:20:48 +0100
message:

MDEV-9489:Assertion `0' failed in Protocol::end_statement() on UNION ALL

Restoring currect_select fixed.

Comment by Oleksandr Byelkin [ 2016-02-18 ]

The bug is present in 5.5/10.0 but test suite is not repetable

Comment by Sergei Petrunia [ 2016-02-19 ]

Ok to push.

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