MySQL Bugs: #21794: MYSQL_STMT operations cause seg fault after connection reset (see bug #12744)

Bug #21794	MYSQL_STMT operations cause seg fault after connection reset (see bug #12744)
Submitted:	23 Aug 2006 13:36	Modified:	28 Sep 2006 22:03
Reporter:	Eric Estabrooks	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	5.0.22	OS:	Linux (linux)
Assigned to:	Assigned Account	CPU Architecture:	Any
Tags:	mysql_stmt_execute, segfault, server connection lost

Description:
I get a segfault when using a prepared statement after a connection reset.  What I saw looks like the description from bug 12744.

fs_sql_getattr called with path /, 0xa7be010c
giving 29544 connection 0x96bd7c8
--- called get connection at line fs_sql.c 268
get_inode_by_path: [/], 2 bind 0x96c59a0, 0x96c59e0
---about to execute 0x96c3e80 at line fs_sql.c 291
---executed 0x96c3e80 at line fs_sql.c 291
mysql_stmt_execute failed MySQL server has gone away 1
putting 0x96bd7c8 by 29544
   unique: 2, error: -2 (No such file or directory), outsize: 16
unique: 3, opcode: GETATTR (3), nodeid: 1, insize: 40
fs_sql_getattr called with path /, 0xafcbf9cc
giving 29544 connection 0x96bd7c8
--- called get connection at line fs_sql.c 268
get_inode_by_path: [/], 2 bind 0x96c59a0, 0x96c59e0
---about to execute 0x96c3e80 at line fs_sql.c 291

Program received signal SIGSEGV, Segmentation fault.

Using debian packages from unstable branch
ii  mysql-client                 5.0.22-4
ii  mysql-client-5.0             5.0.22-4
ii  mysql-common                 5.0.22-4
ii  mysql-server                 5.0.22-4
ii  mysql-server-5.0             5.0.22-4

mysql  Ver 14.12 Distrib 5.0.22, for pc-linux-gnu (i486) using readline 5.1
mysqld  Ver 5.0.22-Debian_4-log for pc-linux-gnu on i486

How to repeat:
init and bind a prepared statement
execute the statement
restart the mysql server
execute the statment

Thank you for the bug report. Could you please provide the code test case,
also have you tested against the latest 5.0.24 release?

Thanks in advance.

code sample that causes segfault

Attachment: sql_fail.c (text/x-csrc), 2.88 KiB.

I haven't tried it against 5.0.24

It looks like 5.0.24 has the problem as well.  I installed the debian packages for 5.0.24 and the segfault still occurs.

mysqld  Ver 5.0.24-Debian_1-log for pc-linux-gnu on i486
mysql  Ver 14.12 Distrib 5.0.24, for pc-linux-gnu (i486) using readline 5.1

Thank you for the feedback. Then could you please provide the code/dump table
test case?

Thanks in advance.

The code is already attached as a file.  

The table is:

create table Inodes (
    inode int unsigned NOT NULL AUTO_INCREMENT PRIMARY KEY,
    rpath varchar(4095) NOT NULL,
    UNIQUE(inode)
);

the entry in the table is:
insert into Inodes(rpath) values('/\0');

Thank you for the feedback. I tested against the current source tree and
I added the below line of code for to verify if the server is sending the
correct error message for to allow to quit the client application gracefully
(which was the bug #12744) and I noticed the correct error message:

fprintf(stderr, "res = %lu,  sleeping 30 seconds, reset mysql server now\n", res);
  sleep(30);
  err = mysql_stmt_execute(stmt);
  if (err != 0) { /* expect the reset connection message here */
    fprintf(stderr, "statement(2) execute failed: %s\n", mysql_stmt_error(stmt));
    if (mysql_stmt_reset(stmt))
     fprintf(stderr, "mysql_stmt_reset error: %s\n", mysql_stmt_error(stmt));
  } else {

miguel@hegel:~/dbs/5.0> ./bug21974
./bug21974: /usr/lib/libmysqlclient.so.15: no version information available (required by ./bug21974)
res = 1,  sleeping 30 seconds, reset mysql server now
statement(2) execute failed: MySQL server has gone away
mysql_stmt_reset error: MySQL server has gone away
Segmentation fault
miguel@hegel:~/dbs/5.0>

You can see above: MySQL server has gone away

What you got here:

if (err != 0) { /* expect the reset connection message here */
  fprintf(stderr, "statement(2) execute failed: %s\n",mysql_stmt_error(stmt));

Thanks in adavance.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".