[MDEV-27649] prepared statement cluster conflict crashing in item parameter setup Created: 2022-01-27  Updated: 2022-03-18  Resolved: 2022-03-18

Status: Closed
Project: MariaDB Server
Component/s: Binary Protocol, Galera, Prepared Statements
Affects Version/s: 10.4, 10.5
Fix Version/s: 10.4.25, 10.5.16, 10.6.8, 10.7.4

Type: Bug Priority: Major
Reporter: Seppo Jaakola Assignee: Jan Lindström (Inactive)
Resolution: Fixed Votes: 0
Labels: None


 Description   

Binary protocol prepared statement execution, which happens after cluster wide conflict, may crash in item parameter setup phase for:

append_query_string (csinfo=0xa5a5a5a5a5a5a5a5, to=0x7fce93673ff0, str=0x7fcea8059458 "", len=11, no_backslash=false)

Where character set info is not valid.

The problem can be reproduced in two node cluster with sysbench:
sysbench --mysql-host=127.0.0.1 --mysql-port=16001 --mysql-user=root --mysql-password= --mysql-db=sbtest --mysql-ignore-errors=all --time=600 --threads=8 --table-size=20 --tables=3 --report-interval=5 /usr/share/sysbench/oltp_write_only.lua run

 Comments   
Comment by Seppo Jaakola [ 2022-01-31 ]

The analysis of this issue revealed that the problem happens if a prepared statement (PS) has been prepared, and the first EXECUTE command will fail due to cluster wide conflict, so early that EXECUTE processing has not yet started. Such situation is possible, e.g. if a PS is executed within a multi statement transaction, and the transaction is holding some offending locks with replicated transactions being applied in the node. And the cluster conflict is detected right after the packet, containing the PS EXECUTE command, has been read from client protocol.
The first EXECUTE command carries type information (e.g. character set definition), and latter EXECUTE commands are optimized to not repeat this type information. The MYSQL_STMT struct in client side appears to maintain MYSQL_STMT::send_type_to_server boolean for this purpose. The server responds with deadlock error when the the first PS EXECUTE fails, but in client side (I assume) send_type_to_server is nevertheless set to true, and following EXECUTE will then not carry type information anymore.
And this is bad, because the first EXECUTE execution did not even start, the type information is not recorded in server side.

Comment by Seppo Jaakola [ 2022-02-22 ]

Two PRs were submitted for this issue.

Comment by Jan Lindström (Inactive) [ 2022-03-18 ]
Generated at Thu Feb 08 09:54:32 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.