Description:
I found a server-side assertion failure while testing MySQL prepared statements through the classic MySQL protocol.
The reproducer sends raw prepared-statement protocol packets directly to the authenticated socket:
1. Raw `COM_STMT_PREPARE`
2. First raw `COM_STMT_EXECUTE`
3. Second raw `COM_STMT_EXECUTE` for the same prepared statement
I expected the server to execute the statement, return result packets, or reject malformed/unusual execute packets with a normal error response. Instead, the server aborted with an assertion failure while processing the second execute packet.
The saved server error log starts with:
```text
mysqld: /home/fhb/mysql-server/sql/sql_cursor.cc:451: virtual Materialized_cursor::~Materialized_cursor(): Assertion `!is_open()' failed.
```
Backtrace excerpt:
```text
#10 Materialized_cursor::~Materialized_cursor at /home/fhb/mysql-server/sql/sql_cursor.cc:451
#13 Query_result_materialize::~Query_result_materialize at /home/fhb/mysql-server/sql/sql_cursor.cc:118
#16 Prepared_statement::~Prepared_statement at /home/fhb/mysql-server/sql/sql_prepare.cc:2302
#17 Prepared_statement::reprepare at /home/fhb/mysql-server/sql/sql_prepare.cc:3407
#18 Prepared_statement::execute_loop at /home/fhb/mysql-server/sql/sql_prepare.cc:3108
#19 mysqld_stmt_execute at /home/fhb/mysql-server/sql/sql_prepare.cc:1902
```
How to repeat:
1. Start a debug/ASan MySQL server build.
2. Install Python dependencies:
```bash
pip install pymysql mysql-connector-python
```
3. Run the attached reproducer against the test server:
```bash
python3 bug_reproduce_4.py -h <host> -P <port> -u <user> -p <password> -d bug4_repro
```
4. The script sends the raw `COM_STMT_PREPARE`, the first raw `COM_STMT_EXECUTE`, and the second raw `COM_STMT_EXECUTE` directly through the socket.
Observed output:
```text
Raw send packet_2_stmt577.bin: COM_STMT_EXECUTE payload_len=28
Connection lost while waiting for packet_2_stmt577.bin: server closed the connection
BUG CONFIRMED: server appears to be down
```
