MySQL Bugs: #44521: Prepared Statement: CALL p() - crashes: `! thd->main_da.is

Bug #44521	Prepared Statement: CALL p() - crashes: `! thd->main_da.is_sent' failed et.al.
Submitted:	28 Apr 2009 14:42	Modified:	18 Dec 2009 13:15
Reporter:	Ulf Wendel	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S1 (Critical)
Version:	5.1.34-debug,6.0	OS:	Linux (x86_64)
Assigned to:	Kristofer Pettersson	CPU Architecture:	Any

Description:
NOTE: This could be a duplicate of http://bugs.mysql.com/bug.php?id=44495 . However, the C-API example is different. The C program will not always crash the server. The crash seems not to be deterministic. I had to run the C program in a loop to make the server crash. Clients of libmysql, such as Connector/C++, can get various error messages ranging from "Lost connection to MySQL server at 'reading authorization packet', system error: 104", "Lost connection to MySQL server at 'reading initial communication packet', system error: 0.", "'Lost connection to MySQL server during query'" to no error at all.

When running the following SQL through the C-API, which works fine on the MySQL prompt, the server will sometimes (not always) crash the server:

nixnutz@ulflinux:~/src/connector-cpp-bzr/trunk> /usr/local/mysql/bin/mysql -uroot -proot test
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.1.34-debug Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> DROP PROCEDURE IF EXISTS p;
Query OK, 0 rows affected (0.00 sec)

mysql> DELIMITER // ;
mysql> CREATE PROCEDURE p() BEGIN SELECT 1 FROM DUAL; END ; //
Query OK, 0 rows affected (0.00 sec)

mysql> DELIMITER ; //
mysql> PREPARE stmt FROM "CALL p()";
Query OK, 0 rows affected (0.00 sec)
Statement prepared

mysql> EXECUTE stmt;
+---+
| 1 |
+---+
| 1 |
+---+
1 row in set (0.00 sec)

Compile the C program and run it multiple (many!) times in a loop. The crash seems not to be deterministic. You will find crashes like:

090428 16:30:01  InnoDB: Started; log sequence number 0 1997339047
090428 16:30:01 [Note] Event Scheduler: Loaded 0 events
090428 16:30:01 [Note] /usr/local/mysql/libexec/mysqld: ready for connections.
Version: '5.1.34-debug'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
090428 16:30:03 mysqld_safe Number of processes running now: 0
090428 16:30:03 mysqld_safe mysqld restarted
mysqld: protocol.cc:386: void net_end_statement(THD*): Assertion `! thd->main_da.is_sent' failed.
090428 16:30:03 - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=8384512
read_buffer_size=131072
max_used_connections=1
max_threads=151
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338311 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x18a9d58
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x44089110 thread_stack 0x40000
/usr/local/mysql/libexec/mysqld(my_print_stacktrace+0x32)[0xafda58]
/usr/local/mysql/libexec/mysqld(handle_segfault+0x28a)[0x6b5268]
/lib64/libpthread.so.0[0x2ac8c0de3fb0]
/lib64/libc.so.6(gsignal+0x35)[0x2ac8c1adfb45]
/lib64/libc.so.6(abort+0x110)[0x2ac8c1ae10e0]
/lib64/libc.so.6(__assert_fail+0xef)[0x2ac8c1ad907f]
/usr/local/mysql/libexec/mysqld(_Z17net_end_statementP3THD+0x3b)[0x6a8f0f]
/usr/local/mysql/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x1cc0)[0x6d15a0]
/usr/local/mysql/libexec/mysqld(_Z10do_commandP3THD+0x24a)[0x6d1936]
/usr/local/mysql/libexec/mysqld(handle_one_connection+0x11c)[0x6be7c0]
/lib64/libpthread.so.0[0x2ac8c0ddc020]
/lib64/libc.so.6(clone+0x6d)[0x2ac8c1b73f8d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x190a450 = CALL p()
thd->thread_id=1
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
090428 16:30:03 mysqld_safe Number of processes running now: 0
090428 16:30:03 mysqld_safe mysqld restarted
090428 16:30:03 [Warning] Ignoring user change to 'ser=mysql' because the user was set to 'mysql' earlier on the command line

090428 16:29:57  InnoDB: Started; log sequence number 0 1997339047
090428 16:29:57 [Note] Event Scheduler: Loaded 0 events
090428 16:29:57 [Note] /usr/local/mysql/libexec/mysqld: ready for connections.
Version: '5.1.34-debug'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
090428 16:30:01 mysqld_safe Number of processes running now: 0
090428 16:30:01 mysqld_safe mysqld restarted
mysqld: sql_class.cc:436: void Diagnostics_area::set_ok_status(THD*, ha_rows, ulonglong, const char*): Assertion `! is_set()' failed.
090428 16:30:01 - mysqld got signal 6 ;
[...]
thd: 0x18a9da8
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x44089110 thread_stack 0x40000
/usr/local/mysql/libexec/mysqld(my_print_stacktrace+0x32)[0xafda58]
/usr/local/mysql/libexec/mysqld(handle_segfault+0x28a)[0x6b5268]
/lib64/libpthread.so.0[0x2ba2cd7b7fb0]
/lib64/libc.so.6(gsignal+0x35)[0x2ba2ce4b3b45]
/lib64/libc.so.6(abort+0x110)[0x2ba2ce4b50e0]
/lib64/libc.so.6(__assert_fail+0xef)[0x2ba2ce4ad07f]
/usr/local/mysql/libexec/mysqld(_ZN16Diagnostics_area13set_ok_statusEP3THDyyPKc+0x42)[0x69c57c]
/usr/local/mysql/libexec/mysqld(_Z5my_okP3THDyyPKc+0x3b)[0x5cb8f7]
/usr/local/mysql/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x7066)[0x6cd6da]
/usr/local/mysql/libexec/mysqld(_ZN18Prepared_statement7executeEP6Stringb+0x4ff)[0x76cf27]
/usr/local/mysql/libexec/mysqld(_ZN18Prepared_statement12execute_loopEP6StringbPhS2_+0x11c)[0x771084]
/usr/local/mysql/libexec/mysqld(_Z18mysql_stmt_executeP3THDPcj+0x205)[0x771573]
/usr/local/mysql/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0xaf2)[0x6d03d2]
/usr/local/mysql/libexec/mysqld(_Z10do_commandP3THD+0x24a)[0x6d1936]
/usr/local/mysql/libexec/mysqld(handle_one_connection+0x11c)[0x6be7c0]
/lib64/libpthread.so.0[0x2ba2cd7b0020]
/lib64/libc.so.6(clone+0x6d)[0x2ba2ce547f8d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x190e3e0 = CALL p()
thd->thread_id=2
thd->killed=NOT_KILLED

The only pattern I see is that one of those two assertions fails:

  mysqld: sql_class.cc:436: void Diagnostics_area::set_ok_status(THD*, ha_rows, ulonglong, const char*): Assertion `! is_set()' failed.

mysqld: protocol.cc:386: void net_end_statement(THD*): Assertion `! thd->main_da.is_sent' failed.

How to repeat:
#include "stdio.h"
#include "stdlib.h"
#include "string.h"
#include <my_global.h>
#include <my_sys.h>
#include <mysql.h>

int exit_failure(const char *msg, MYSQL *mysql, MYSQL_RES *res, MYSQL_STMT *stmt);

/* Connection parameter - change */
const char *con_host = "localhost";
const char *con_user = "root";
const char *con_pass = "root";
const char *con_db = "test";
unsigned int con_port = 3306;
const char *con_socket = "/tmp/mysql.sock";
unsigned long con_flags = CLIENT_MULTI_RESULTS;

/* SQL statement */
const char* sql_drop = "DROP PROCEDURE IF EXISTS p";
const char* sql_proc = "CREATE PROCEDURE p() BEGIN SELECT 1; END;";
const char* sql_call = "CALL p()";

int main(void) {
	MYSQL *conn;
	MYSQL_RES *res;
	MYSQL_STMT *stmt;
	MYSQL_BIND bind[1];
	int column1;
	unsigned long length;
	my_bool is_null;
	my_bool error;
	int ret;
	unsigned int i;
	int status;

	printf("\n");

	conn = mysql_init(NULL);
	if (conn == NULL)
		exit_failure("mysql_init() failed", NULL, NULL, NULL);

	if (mysql_real_connect(conn, con_host, con_user, con_pass, con_db, con_port, con_socket, con_flags) == NULL)
		exit_failure("mysql_real_connect() failed", conn, NULL, NULL);

	printf("Server: 	%s\n", mysql_get_server_info(conn));
	printf("Protocol: 	%u\n", mysql_get_proto_info(conn));
	printf("Client: 	%s\n\n", mysql_get_client_info());

	printf("CALL using stmt_prepare()/stmt_execute...\n");
	stmt = mysql_stmt_init(conn);
	if (mysql_stmt_prepare(stmt, sql_call, (unsigned long)strlen(sql_call)))
		exit_failure("mysql_stmt_prepare() failed", conn, NULL, stmt);

	if (mysql_stmt_execute(stmt))
		exit_failure("mysql_stmt_execute() failed", conn, NULL, stmt);

	mysql_stmt_close(stmt);
	mysql_close(conn);
	printf("\n");

	return EXIT_SUCCESS;
}

int exit_failure(const char *msg, MYSQL *mysql, MYSQL_RES *res, MYSQL_STMT *stmt) {
	printf("ERROR: %s\n", msg);
	if (stmt) {
		printf("[%u] %s\n", mysql_stmt_errno(stmt), mysql_stmt_error(stmt));
		mysql_stmt_close(stmt);
	}
	if (mysql) {
		if (mysql_errno(mysql))
			printf("[%u] %s\n", mysql_errno(mysql), mysql_error(mysql));
		if (res)
			mysql_free_result(res);
		mysql_close(mysql);
	}
	printf("\n");
	exit(EXIT_FAILURE);
}

The example code stinks, sorry, ... It lacks drop/create.

#include "stdio.h"
#include "stdlib.h"
#include "string.h"
#include <my_global.h>
#include <my_sys.h>
#include <mysql.h>

int exit_failure(const char *msg, MYSQL *mysql, MYSQL_RES *res, MYSQL_STMT *stmt);

/* Connection parameter - change */
const char *con_host = "localhost";
const char *con_user = "root";
const char *con_pass = "root";
const char *con_db = "test";
unsigned int con_port = 3306;
const char *con_socket = "/tmp/mysql.sock";
unsigned long con_flags = CLIENT_MULTI_RESULTS;

/* SQL statement */
const char* sql_drop = "DROP PROCEDURE IF EXISTS p";
const char* sql_proc = "CREATE PROCEDURE p() BEGIN SELECT 1; END;";
const char* sql_call = "CALL p()";

int main(void) {
	MYSQL *conn;
	MYSQL_STMT *stmt;

	printf("\n");

	conn = mysql_init(NULL);
	if (conn == NULL)
		exit_failure("mysql_init() failed", NULL, NULL, NULL);

	if (mysql_real_connect(conn, con_host, con_user, con_pass, con_db, con_port, con_socket, con_flags) == NULL)
		exit_failure("mysql_real_connect() failed", conn, NULL, NULL);

	printf("Server: 	%s\n", mysql_get_server_info(conn));
	printf("Protocol: 	%u\n", mysql_get_proto_info(conn));
	printf("Client: 	%s\n\n", mysql_get_client_info());

	if (mysql_real_query(conn, sql_drop, (unsigned long)strlen(sql_drop)))
		exit_failure(sql_drop, conn, NULL, NULL);

	if (mysql_real_query(conn, sql_proc, (unsigned long)strlen(sql_proc)))
		exit_failure(sql_proc, conn, NULL, NULL);

	printf("CALL using stmt_prepare()/stmt_execute...\n");
	stmt = mysql_stmt_init(conn);
	if (mysql_stmt_prepare(stmt, sql_call, (unsigned long)strlen(sql_call)))
		exit_failure("mysql_stmt_prepare() failed", conn, NULL, stmt);

	if (mysql_stmt_execute(stmt))
		exit_failure("mysql_stmt_execute() failed", conn, NULL, stmt);

	mysql_stmt_close(stmt);
	mysql_close(conn);
	printf("\n");

	return EXIT_SUCCESS;
}

int exit_failure(const char *msg, MYSQL *mysql, MYSQL_RES *res, MYSQL_STMT *stmt) {
	printf("ERROR: %s\n", msg);
	if (stmt) {
		printf("[%u] %s\n", mysql_stmt_errno(stmt), mysql_stmt_error(stmt));
		mysql_stmt_close(stmt);
	}
	if (mysql) {
		if (mysql_errno(mysql))
			printf("[%u] %s\n", mysql_errno(mysql), mysql_error(mysql));
		if (res)
			mysql_free_result(res);
		mysql_close(mysql);
	}
	printf("\n");
	exit(EXIT_FAILURE);
}

5.4 is doing better than 5.1.34 as it seems, but I can make it crash as well:

Version: '5.4.0-beta-debug'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
mysqld: sql_class.cc:436: void Diagnostics_area::set_ok_status(THD*, ha_rows, ulonglong, const char*): Assertion `! is_set()' failed.

If you have problems reproducing the crash, change the code of the stored procedure and make it return multiple result sets:

const char* sql_proc = "CREATE PROCEDURE p() BEGIN SELECT 1; SELECT 2; SELECT 3; END;";

I am not sure if this detail (multiple result sets) is important. I thought I checked it and it would not be important.

Thank you for the feedback.

I can not repeat this too. Could you please check with today bzr sources and if bug still repeatable for you provide your configuration file and options you compiled mysqld with?

Sure, I can check the latest sources, if you tell me the URL of the bzr tree to check. Sorry, but I'm not following server development much and I don't know what bzr tree to use...

Thank you for the feedback.

You can use this URL: https://code.launchpad.net/~mysql/mysql-server/mysql-5.1

nixnutz@ulflinux:~/src> rm -rf mysql-5.1/ ; bzr clone bzr+ssh://uwendel@bk-internal.mysql.com/bzrroot/server/mysql-5.1/
bzr: WARNING: bzrlib version doesn't match the bzr program.
This may indicate an installation problem.
bzrlib from ['/usr/lib64/python2.5/site-packages/bzrlib'] is version (1, 14, 1, 'final', 0)
'BranchHooks' object has no attribute 'install_hook'
Unable to load plugin 'mysql_plugins' from '/home/nixnutz/.bazaar/plugins'
uwendel@bk-internal.mysql.com's password:     0KB/s |
Permission denied, please try again.
uwendel@bk-internal.mysql.com's password:
Branched 2853 revision(s).
nixnutz@ulflinux:~/src> cd mysql-5.1/
nixnutz@ulflinux:~/src/mysql-5.1> BUILD/compile-pentium-debug-max
testing core2 ... ok
[...]

gmake[2]: Leaving directory `/home/nixnutz/src/mysql-5.1/server-tools/instance-manager'
gmake[1]: Leaving directory `/home/nixnutz/src/mysql-5.1/server-tools'
Making all in win
gmake[1]: Entering directory `/home/nixnutz/src/mysql-5.1/win'
gmake[1]: Warnung: -jN in »make«-Verarbeitungszweig erzwungen:
Jobserver-Modus nicht verfügbar.
gmake[1]: Für das Ziel »all« ist nichts zu tun.
gmake[1]: Leaving directory `/home/nixnutz/src/mysql-5.1/win'

nixnutz@ulflinux:~> CFG=/usr/local/mysql/bin/mysql_config
nixnutz@ulflinux:~> rm ./sp_crash; sh -c "gcc -o sp_crash `$CFG --cflags` sp_crash2.c `$CFG --libs`"
nixnutz@ulflinux:~> /usr/local/mysql/bin/mysql_config
Usage: /usr/local/mysql/bin/mysql_config [OPTIONS]
Options:
        --cflags         [-I/usr/local/mysql/include/mysql -g -Wreturn-type -Wtrigraphs -W -Wformat -Wsign-compare -Wunused-function -Wunused-value -Wunused-parameter -DUNIV_LINUX]
        --include        [-I/usr/local/mysql/include/mysql]
        --libs           [-rdynamic -L/usr/local/mysql/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm]
        --libs_r         [-rdynamic -L/usr/local/mysql/lib/mysql -lmysqlclient_r -lz -lpthread -lcrypt -lnsl -lm -lpthread]
        --plugindir      [/usr/local/mysql/lib/mysql/plugin]
        --socket         [/tmp/mysql.sock]
        --port           [0]
        --version        [5.1.35]
        --libmysqld-libs [-rdynamic -L/usr/local/mysql/lib/mysql -lmysqld -ldl -lz -lpthread -lcrypt -lnsl -lm -lpthread -lrt]
nixnutz@ulflinux:~> ldd ./sp_crash
        libmysqlclient.so.16 => /usr/local/mysql/lib/mysql/libmysqlclient.so.16 (0x00002ad0d2bb9000)
        libz.so.1 => /lib64/libz.so.1 (0x00002ad0d3043000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002ad0d3258000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00002ad0d3491000)
        libm.so.6 => /lib64/libm.so.6 (0x00002ad0d36a9000)
        libc.so.6 => /lib64/libc.so.6 (0x00002ad0d38fc000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ad0d3c41000)
        /lib64/ld-linux-x86-64.so.2 (0x00002ad0d299c000)
nixnutz@ulflinux:~> ./sp_crash

Server:         5.1.35-debug
Protocol:       10
Client:         5.1.35

...running: 'DROP PROCEDURE IF EXISTS p'
...running: 'CREATE PROCEDURE p() BEGIN SELECT 1; SELECT 2; SELECT 3; END;'

CALL using stmt_prepare()/stmt_execute...
...preparing: 'CALL p()'
...executing: 'CALL p()'

nixnutz@ulflinux:~> 090505 13:23:33 mysqld_safe Number of processes running now: 0
090505 13:23:33 mysqld_safe mysqld restarted

#include "stdio.h"
#include "stdlib.h"
#include "string.h"
#include <my_global.h>
#include <my_sys.h>
#include <mysql.h>

int exit_failure(const char *msg, MYSQL *mysql, MYSQL_RES *res, MYSQL_STMT *stmt);

/* Connection parameter - change */
const char *con_host = "localhost";
const char *con_user = "root";
const char *con_pass = "root";
const char *con_db = "test";
unsigned int con_port = 3306;
const char *con_socket = "/tmp/mysql.sock";
unsigned long con_flags = CLIENT_MULTI_RESULTS;

/* SQL statement */
const char* sql_drop = "DROP PROCEDURE IF EXISTS p";
const char* sql_proc = "CREATE PROCEDURE p() BEGIN SELECT 1; SELECT 2; SELECT 3; END;";
const char* sql_call = "CALL p()";

int main(void) {
	MYSQL *conn;
	MYSQL_STMT *stmt;

	printf("\n");

	conn = mysql_init(NULL);
	if (conn == NULL)
		exit_failure("mysql_init() failed", NULL, NULL, NULL);

	if (mysql_real_connect(conn, con_host, con_user, con_pass, con_db, con_port, con_socket, con_flags) == NULL)
		exit_failure("mysql_real_connect() failed", conn, NULL, NULL);

	printf("Server: 	%s\n", mysql_get_server_info(conn));
	printf("Protocol: 	%u\n", mysql_get_proto_info(conn));
	printf("Client: 	%s\n\n", mysql_get_client_info());

	printf("...running: '%s'\n", sql_drop);
	if (mysql_real_query(conn, sql_drop, (unsigned long)strlen(sql_drop)))
		exit_failure(sql_drop, conn, NULL, NULL);

	printf("...running: '%s'\n\n", sql_proc);
	if (mysql_real_query(conn, sql_proc, (unsigned long)strlen(sql_proc)))
		exit_failure(sql_proc, conn, NULL, NULL);

	printf("CALL using stmt_prepare()/stmt_execute...\n");
	stmt = mysql_stmt_init(conn);
    printf("...preparing: '%s'\n", sql_call);
	if (mysql_stmt_prepare(stmt, sql_call, (unsigned long)strlen(sql_call)))
		exit_failure("mysql_stmt_prepare() failed", conn, NULL, stmt);

    printf("...executing: '%s'\n", sql_call);
	if (mysql_stmt_execute(stmt))
		exit_failure("mysql_stmt_execute() failed", conn, NULL, stmt);

	mysql_stmt_close(stmt);
	mysql_close(conn);
	printf("\n");

	return EXIT_SUCCESS;
}

int exit_failure(const char *msg, MYSQL *mysql, MYSQL_RES *res, MYSQL_STMT *stmt) {
	printf("ERROR: %s\n", msg);
	if (stmt) {
		printf("[%u] %s\n", mysql_stmt_errno(stmt), mysql_stmt_error(stmt));
		mysql_stmt_close(stmt);
	}
	if (mysql) {
		if (mysql_errno(mysql))
			printf("[%u] %s\n", mysql_errno(mysql), mysql_error(mysql));
		if (res)
			mysql_free_result(res);
		mysql_close(mysql);
	}
	printf("\n");
	exit(EXIT_FAILURE);
}

I was able to repeat with latest C test case:

c:\dbs>c:\dbs\5.1\bin\mysqld-debug --defaults-file=c:\dbs\5.1\my.ini --standalone --console
090507 11:46:21  InnoDB: Started; log sequence number 0 82507
090507 11:46:22 [Note] Event Scheduler: Loaded 0 events
090507 11:46:22 [Note] c:\dbs\5.1\bin\mysqld-debug: ready for connections.
Version: '5.1.35-Win X64 revno: 2853-debug-log'  socket: ''  port: 3510  Source distribution
Assertion failed: ! is_set(), file .\sql_class.cc, line 436
090507 11:46:47 - mysqld got exception 0x80000003 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=8384512
read_buffer_size=131072
max_used_connections=1
max_threads=151
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338114 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x7f7abf8
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
00000001401E11A5    mysqld-debug.exe!my_sigabrt_handler()[mysqld.cc:2013]
0000000140745921    mysqld-debug.exe!raise()[winsig.c:597]
000000014076D743    mysqld-debug.exe!__crtMessageWindowA()[dbgrpt.c:434]
000000014074688C    mysqld-debug.exe!_VCrtDbgReportA()[dbgrptt.c:420]
000000014076D183    mysqld-debug.exe!_CrtDbgReportV()[dbgrpt.c:301]
000000014076D11D    mysqld-debug.exe!_CrtDbgReport()[dbgrpt.c:317]
000000014075BE7B    mysqld-debug.exe!_NMSG_WRITE()[crt0msg.c:197]
0000000140738A97    mysqld-debug.exe!abort()[abort.c:68]
0000000140731434    mysqld-debug.exe!_wassert()[assert.c:212]
00000001402EB86C    mysqld-debug.exe!Diagnostics_area::set_ok_status()[sql_class.cc:436]
00000001402382BE    mysqld-debug.exe!my_ok()[sql_class.h:2262]
000000014034447D    mysqld-debug.exe!mysql_execute_command()[sql_parse.cc:4338]
0000000140380FAB    mysqld-debug.exe!Prepared_statement::execute()[sql_prepare.cc:3568]
000000014037FF5C    mysqld-debug.exe!Prepared_statement::execute_loop()[sql_prepare.cc:3241]
0000000140379493    mysqld-debug.exe!mysql_stmt_execute()[sql_prepare.cc:2464]
000000014033B0D3    mysqld-debug.exe!dispatch_command()[sql_parse.cc:1172]
000000014033A5F7    mysqld-debug.exe!do_command()[sql_parse.cc:857]
00000001402FE8B6    mysqld-debug.exe!handle_one_connection()[sql_connect.cc:1115]
000000014053CAA5    mysqld-debug.exe!pthread_start()[my_winthread.c:85]
0000000140747935    mysqld-debug.exe!_callthreadstart()[thread.c:295]
0000000140747907    mysqld-debug.exe!_threadstart()[thread.c:277]
00000000772FC3BD    kernel32.dll!BaseThreadInitThunk()
0000000077684581    ntdll.dll!RtlUserThreadStart()
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0000000008008418=CALL p()
thd->thread_id=1
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Thank you for the bug report.

Back trace for 6.0

Attachment: stacktrace6.txt (text/plain), 4.66 KiB.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/77708

2935 Kristofer Pettersson	2009-07-01
      Bug#44521 Prepared Statement: CALL p() - crashes: `! thd->main_da.is_sent' failed et.al.
       
      For discussion.
      
      Executing a stored procedure as a prepared statement can sometimes cause an 
      assertion in a debug build.
      
      The reason is that the C API doesn't support multiple result sets for prepared
      statements and attempting to execute a stored routine which returns multiple result
      sets sometimes lead to a network error. The network error sets the diagnostic area
      prematurely which later leads to the assert when an attempt is made to set a second
      server state.
      
      This patch fixes the issue by changing the scope of the error code returned by
      sp_instr_stmt::execute() to include any error which happened during the execution.
      An extra check is also made to make sure that the diagnostic area isn't set twice.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/78729

3017 Konstantin Osipov	2009-07-15
      A fix for Bug#44521 "Prepared Statement: CALL p() - crashes: `! thd->main_da.is_sent' 
      failed et.al."
      
      The bug was fixed 1 year ago in WL#2983 tree.

Just for reference: it was fixed in WL#2793.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/78825

2935 Kristofer Pettersson	2009-07-16
      Bug#44521 Executing a stored procedure as a prepared statement can sometimes cause an 
                assertion in a debug build.
      
      (for discussion)
      
      The reason is that the C API doesn't support multiple result sets for prepared
      statements and attempting to execute a stored routine which returns multiple result
      sets sometimes lead to a network error. The network error sets the diagnostic area
      prematurely which later leads to the assert when an attempt is made to set a second
      server state.
      
      This patch fixes the issue by changing the scope of the error code returned by
      sp_instr_stmt::execute() to include any error which happened during the execution.
      To assure that Diagnostic_area::is_sent really mean that the message was sent all
      network related functions are checked for return status.
     @ sql/protocol.cc
        * Changed prototype to return success/failure status on net_send_error_packet(),
          net_send_ok(), net_send_eof(), write_eof_packet().
     @ sql/protocol.h
        * Changed prototype on net_send_error() so that a success/failure status is reported.
     @ sql/sp_head.cc
        * If any error has been reported inside sp_instr_stmt::execute() the entire method should return
          a failure status.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/78899

2935 Kristofer Pettersson	2009-07-17
      Bug#44521 Executing a stored procedure as a prepared statement can sometimes cause an 
                assertion in a debug build.
      
      The reason is that the C API doesn't support multiple result sets for prepared
      statements and attempting to execute a stored routine which returns multiple result
      sets sometimes lead to a network error. The network error sets the diagnostic area
      prematurely which later leads to the assert when an attempt is made to set a second
      server state.
      
      This patch fixes the issue by changing the scope of the error code returned by
      sp_instr_stmt::execute() to include any error which happened during the execution.
      To assure that Diagnostic_area::is_sent really mean that the message was sent all
      network related functions are checked for return status.
     @ sql/protocol.cc
        * Changed prototype to return success/failure status on net_send_error_packet(),
          net_send_ok(), net_send_eof(), write_eof_packet().
     @ sql/protocol.h
        * Changed prototype on net_send_error() so that a success/failure status is
          reported.
     @ sql/sp_head.cc
        * If any error has been reported inside sp_instr_stmt::execute() the entire method
          should return a failure status.
     @ sql/sql_class.cc
        * If always reset is_sent if a new error is written over current state in the DA.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/79353

2935 Kristofer Pettersson	2009-07-27
      Bug#44521 Executing a stored procedure as a prepared statement can sometimes cause
                an assertion in a debug build.
      
      The reason is that the C API doesn't support multiple result sets for prepared
      statements and attempting to execute a stored routine which returns multiple result
      sets sometimes lead to a network error. The network error sets the diagnostic area
      prematurely which later leads to the assert when an attempt is made to set a second
      server state.
      
      This patch fixes the issue by changing the scope of the error code returned by
      sp_instr_stmt::execute() to include any error which happened during the execution.
      To assure that Diagnostic_area::is_sent really mean that the message was sent all
      network related functions are checked for return status.
     @ sql/net_serv.cc
        * Added error injection code.
        * Removed debug assert in order to get proper error code in debug build.
     @ sql/protocol.cc
        * Changed prototype to return success/failure status on net_send_error_packet(),
          net_send_ok(), net_send_eof(), write_eof_packet().
     @ sql/protocol.h
        * Changed prototype on net_send_error() so that a success/failure status is
          reported.
     @ sql/sp_head.cc
        * If any error has been reported inside sp_instr_stmt::execute() the entire method
          should return a failure status.
     @ sql/sql_parse.cc
        * Added error injection code for the regression test.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/79497

3045 Kristofer Pettersson	2009-07-29
      Bug#44521 Executing a stored procedure as a prepared statement can sometimes cause
                an assertion in a debug build.
      
      The reason is that the C API doesn't support multiple result sets for prepared
      statements and attempting to execute a stored routine which returns multiple result
      sets sometimes lead to a network error. The network error sets the diagnostic area
      prematurely which later leads to the assert when an attempt is made to set a second
      server state.
      
      This patch fixes the issue by changing the scope of the error code returned by
      sp_instr_stmt::execute() to include any error which happened during the execution.
      To assure that Diagnostic_area::is_sent really mean that the message was sent all
      network related functions are checked for return status.
     @ mysql-test/r/sp.result
        * Added test case for bug 44521
     @ mysql-test/t/sp.test
        * Added test case for bug 44521
     @ sql/protocol.cc
        * Changed prototype to return success/failure status on net_send_error_packet(),
          net_send_ok(), net_send_eof(), write_eof_packet().
     @ sql/protocol.h
        * Changed prototype to return success/failure status on net_send_error_packet(),
          net_send_ok(), net_send_eof(), write_eof_packet().
     @ sql/sp_head.cc
        * Changed prototype to return success/failure status on net_send_error_packet(),
          net_send_ok(), net_send_eof(), write_eof_packet().

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/79564

3045 Kristofer Pettersson	2009-07-29
      Bug#44521 Executing a stored procedure as a prepared statement can sometimes cause
                an assertion in a debug build.
      
      The reason is that the C API doesn't support multiple result sets for prepared
      statements and attempting to execute a stored routine which returns multiple result
      sets sometimes lead to a network error. The network error sets the diagnostic area
      prematurely which later leads to the assert when an attempt is made to set a second
      server state.
      
      This patch fixes the issue by changing the scope of the error code returned by
      sp_instr_stmt::execute() to include any error which happened during the execution.
      To assure that Diagnostic_area::is_sent really mean that the message was sent all
      network related functions are checked for return status.
     @ libmysqld/lib_sql.cc
        * Changed prototype to return success/failure status on net_send_error_packet(),
          net_send_ok(), net_send_eof(), write_eof_packet().
     @ mysql-test/r/sp_notembedded.result
        * Added test case for bug 44521
     @ mysql-test/t/sp_notembedded.test
        * Added test case for bug 44521
     @ sql/protocol.cc
        * Changed prototype to return success/failure status on net_send_error_packet(),
          net_send_ok(), net_send_eof(), write_eof_packet().
     @ sql/protocol.h
        * Changed prototype to return success/failure status on net_send_error_packet(),
          net_send_ok(), net_send_eof(), write_eof_packet().
     @ sql/sp_head.cc
        * Changed prototype to return success/failure status on net_send_error_packet(),
          net_send_ok(), net_send_eof(), write_eof_packet().

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/79583

3047 Kristofer Pettersson	2009-07-30
      Bug#44521 Prepared Statement: CALL p() - crashes: `! thd->main_da.is_sent' failed et.al.
      
      Fixed wrong prototype declaration which cased build failure on solaris.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/79696

3491 Kristofer Pettersson	2009-07-30
      Bug#44521 Executing a stored procedure as a prepared statement can sometimes cause
                an assertion in a debug build.
      
      The reason is that the C API doesn't support multiple result sets for prepared
      statements and attempting to execute a stored routine which returns multiple result
      sets sometimes lead to a network error. The network error sets the diagnostic area
      prematurely which later leads to the assert when an attempt is made to set a second
      server state.
      
      This patch fixes the issue by changing the scope of the error code returned by
      sp_instr_stmt::execute() to include any error which happened during the execution.
      To assure that Diagnostic_area::is_sent really mean that the message was sent all
      network related functions are checked for return status.
     @ sql/protocol.cc
        * Changed prototype to return success/failure status on net_send_error_packet(),
          net_send_ok(), net_send_eof(), write_eof_packet().
     @ sql/protocol.h
        * Changed prototype to return success/failure status on net_send_error_packet(),
          net_send_ok(), net_send_eof(), write_eof_packet().
        * Changed protoype on virtual methods send_eof(), send_error() and send_ok()
     @ sql/sp_head.cc
        * If any error has been reported inside sp_instr_stmt::execute() the entire method
          should return a failure status.
     @ sql/sql_prepare.cc
        * Adjusted implementation of base class prototype change to methods send_ok(), send_error() and send_eof()

Pushed into 5.4.4-alpha (revid:alik@sun.com-20090804194615-h40sa098mx4z49qg) (version source revid:kristofer.pettersson@sun.com-20090730162241-03jrbif9dds7d6sw) (merge vers: 5.4.4-alpha) (pib:11)

Pushed into 5.1.38 (revid:davi.arnaut@sun.com-20090804204317-ggodqkik7de6nfpz) (version source revid:davi.arnaut@sun.com-20090804204317-ggodqkik7de6nfpz) (merge vers: 5.1.38) (pib:11)

Noted in 5.1.38, 5.4.4 changelogs.

For debug builds, executing a stored procedure as a prepared
statement could sometimes cause an assertion failure.

Noted in 5.4.2 changelog because next 5.4 version will be 5.4.2 and not 5.4.4.

Ignore previous comment about 5.4.2.

Pushed into 5.1.39-ndb-6.3.28 (revid:jonas@mysql.com-20091001055605-ap2kiaarr7p40mmv) (version source revid:jonas@mysql.com-20091001055605-ap2kiaarr7p40mmv) (merge vers: 5.1.39-ndb-6.3.28) (pib:11)

Pushed into 5.1.39-ndb-7.0.9 (revid:jonas@mysql.com-20091001072547-kv17uu06hfjhgjay) (version source revid:jonas@mysql.com-20091001071652-irejtnumzbpsbgk2) (merge vers: 5.1.39-ndb-7.0.9) (pib:11)

Pushed into 5.1.39-ndb-7.1.0 (revid:jonas@mysql.com-20091001123013-g9ob2tsyctpw6zs0) (version source revid:jonas@mysql.com-20091001123013-g9ob2tsyctpw6zs0) (merge vers: 5.1.39-ndb-7.1.0) (pib:11)

Pushed into 5.1.39-ndb-6.2.19 (revid:jonas@mysql.com-20091005103850-dwij2dojwpvf5hi6) (version source revid:jonas@mysql.com-20090930185117-bhud4ek1y0hsj1nv) (merge vers: 5.1.39-ndb-6.2.19) (pib:11)

Pushed into 5.1.41 (revid:build@mysql.com-20091013182142-vgsjky3t1v4btufv) (version source revid:build@mysql.com-20091013182142-vgsjky3t1v4btufv) (merge vers: 5.1.41) (pib:13)

Already fixed in 5.1.38.

Pushed into 6.0.14-alpha (revid:alik@sun.com-20091022063126-l0qzirh9xyhp0bpc) (version source revid:alik@sun.com-20091019135554-s1pvptt6i750lfhv) (merge vers: 6.0.14-alpha) (pib:13)

Pushed into 5.5.0-beta (revid:alik@sun.com-20091022060553-znkmxm0g0gm6ckvw) (version source revid:alik@sun.com-20091019131937-nchb8tjk88jpfjav) (merge vers: 5.5.0-beta) (pib:13)

Noted in 5.5.0, 6.0.14 changelogs.

Pushed into 5.1.41-ndb-7.1.0 (revid:jonas@mysql.com-20091218102229-64tk47xonu3dv6r6) (version source revid:jonas@mysql.com-20091218095730-26gwjidfsdw45dto) (merge vers: 5.1.41-ndb-7.1.0) (pib:15)

Pushed into 5.1.41-ndb-6.2.19 (revid:jonas@mysql.com-20091218100224-vtzr0fahhsuhjsmt) (version source revid:jonas@mysql.com-20091217101452-qwzyaig50w74xmye) (merge vers: 5.1.41-ndb-6.2.19) (pib:15)

Pushed into 5.1.41-ndb-6.3.31 (revid:jonas@mysql.com-20091218100616-75d9tek96o6ob6k0) (version source revid:jonas@mysql.com-20091217154335-290no45qdins5bwo) (merge vers: 5.1.41-ndb-6.3.31) (pib:15)

Pushed into 5.1.41-ndb-7.0.11 (revid:jonas@mysql.com-20091218101303-ga32mrnr15jsa606) (version source revid:jonas@mysql.com-20091218064304-ezreonykd9f4kelk) (merge vers: 5.1.41-ndb-7.0.11) (pib:15)

Already documented in 5.1.41