[MDEV-17610] Unexpected connection abort after certain operations from within stored procedure Created: 2018-11-03  Updated: 2019-09-03  Resolved: 2019-04-04

Status: Closed
Project: MariaDB Server
Component/s: Prepared Statements, Scripts & Clients, Stored routines
Affects Version/s: 5.5, 10.0, 10.1, 10.2, 10.3, 10.4
Fix Version/s: 10.2.24, 5.5.64, 10.1.39, 10.3.15, 10.4.4

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Vladislav Vaintroub
Resolution: Fixed Votes: 0
Labels: affects-tests

Issue Links:
Relates
relates to MDEV-15800 Assertion `next_insert_id >= auto_inc... Closed

 Description    

CREATE PROCEDURE sp() ALTER TABLE non_existing_table OPTIMIZE PARTITION p0;
 
CALL sp;
 
SELECT 1;
 
 
 
# Cleanup
 
DROP PROCEDURE sp;

Actual result

 
MariaDB [test]> CREATE PROCEDURE sp() ALTER TABLE non_existing_table OPTIMIZE PARTITION p0;
 
Query OK, 0 rows affected (0.04 sec)
 
 
 
MariaDB [test]> CALL sp;
 
+-------------------------+----------+----------+-----------------------------------------------+
 
| Table                   | Op       | Msg_type | Msg_text                                      |
 
+-------------------------+----------+----------+-----------------------------------------------+
 
| test.non_existing_table | optimize | Error    | Table 'test.non_existing_table' doesn't exist |
 
| test.non_existing_table | optimize | status   | Operation failed                              |
 
+-------------------------+----------+----------+-----------------------------------------------+
 
2 rows in set (0.00 sec)
 
 
 
MariaDB [test]> select 1;
 
ERROR 2013 (HY000): Lost connection to MySQL server during query

Another example:

CREATE PROCEDURE sp() SHOW USER_STATISTICS;
 
CALL sp;
 
 
 
SELECT "Still here" AS check_alive;
 
 
 
# Cleanup
 
DROP PROCEDURE sp;

The server doesn't crash, it's really just a connection loss.
The problem is also reproducible with 10.1 client + 10.2+ server, but does not seem to be reproducible with 10.2 client + 10.1 server (or 10.2 + 10.2 and higher).

However, 10.2+ shows a different problem on the same test case, but with --ps-protocol:

CREATE PROCEDURE sp() ALTER TABLE non_existing_table OPTIMIZE PARTITION p0;
 
CALL sp;
 
Table	Op	Msg_type	Msg_text
 
test.non_existing_table	optimize	Error	Table 'test.non_existing_table' doesn't exist
 
test.non_existing_table	optimize	status	Operation failed
 
SELECT 1;
 
bug2.ps1d                                [ fail ]
 
        Test ended at 2019-03-14 19:19:43
 
 
 
CURRENT_TEST: bug2.ps1d
 
mysqltest: At line 3: query 'SELECT 1' failed: 2031: No data supplied for parameters in prepared statement



 Comments   
Comment by Elena Stepanova [ 2018-12-25 ]

Assigning to serg for dispatching, I don't know to whom it should belong, if anyone.

Comment by Vladislav Vaintroub [ 2019-04-03 ]

there is an extra OK packet sent by the server as part of CALL sp
i.e there is

  • a resultset that does not end with STATUS_MORE_RESULTS_EXIST
  • an OK packet after this, that client does not expect

client, after SELECT "Still here"

  • gets an OK packet it does not expect (from the previous CALL sp)
  • pkt_nr in this packet is 27 . In 5.5, client chokes on that, as it expects pkt_nr=1, and closes connection. In 10.2+, client does not close connection, but it still does not expect this OK packet.
Comment by Vladislav Vaintroub [ 2019-04-04 ]

Ok, the actual problem is the missing MORE_RESULTS_EXIST flag after result set

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