Bug #29470 various crashes in libmysql, prepared statements, after kill or kill query.
Submitted: 1 Jul 2007 15:18 Modified: 7 Aug 2007 9:15
Reporter: Shane Bester (Platinum Quality Contributor) Email Updates:
Status: Duplicate Impact on me:
Category:MySQL Server: C API (client library) Severity:S3 (Non-critical)
Version:5.0.44 OS:Any
Assigned to: CPU Architecture:Any
Tags: MYSQL_OPT_RECONNECT, mysql_stmt_execute

[1 Jul 2007 15:18] Shane Bester
Although my application does every possible check after each api call, the libmysql still crashes in some places when the connection to the server is terminated by KILL <id> or KILL QUERY <id>.

Some stack traces:

libmysql.dll!net_clear(st_net * net=0x01d14108)Line 294
libmysql.dll!cli_stmt_execute(st_mysql_stmt * stmt=0x01d28108)Line 2542
libmysql.dll!mysql_stmt_execute(st_mysql_stmt * stmt=0x01d28108)Line 2889C

libmysql.dll!cli_read_binary_rows(st_mysql_stmt * stmt=0x01d1f028)Line 4665
libmysql.dll!mysql_stmt_store_result(st_mysql_stmt * stmt=0x01d1f028)Line 4817

How to repeat:
I will try make a standalone testcase to show this.

Suggested fix:
[1 Jul 2007 21:52] Shane Bester
Hmm.  Repeated in a controlled environment on linux.

(gdb) bt
#0  0x4009a4c3 in net_clear (net=0x804c0a8) at net.c:305
#1  0x40060d44 in cli_stmt_execute (stmt=0x80616a0) at libmysql.c:2544
#2  0x4006149d in mysql_stmt_execute (stmt=0x80616a0) at libmysql.c:2891
#3  0x08048c89 in main () at bug29470.c:78

It seems that when mysql_stmt_execute() fails, you have to re-init and/or re-prepare the statement, otherwise sometimes this crash is seen.

MYSQL_OPT_RECONNECT enabled with my tests.  Another often seen error when a connection is killed:

mysql_stmt_execute failed: Unknown prepared statement handler (39) given to mysql_stmt_execute (1243).  So, I think a bug still exists (even if the crash can be avoided in the client).  The client library is sending incorrect stmt_id to the server..
[1 Jul 2007 22:39] Shane Bester
That second stack trace appears to be a bug in mysql client libs.

!cli_read_binary_rows(st_mysql_stmt * stmt=0x01d6c9a0)
!mysql_stmt_store_result(st_mysql_stmt * stmt=0x01d6c9a0)
!prepared_query_results(st_mysql_stmt * stmt=0x01d6c9a0 ...
!db_pthread(void * arg=0x00000002)

mysql_stmt_store_result(stmt); was called. stmt and stmt->mysql are valid at top of that function.  Further down, when cli_read_binary_rows is called by mysql_stmt_store_result, then somehow stmt->mysql is NULL already.

Need to investigate this further.  Happens in a very small time interval, maybe once in a few minutes, when running at 600qps.
[7 Aug 2007 9:15] Shane Bester
closing as duplicate.  The crashes are caused by CURSOR_TYPE_READ_ONLY which I have noted in bug #29948