MySQL Bugs: #19855: running mabackup causes MySQL Server crash

Bug #19855	running mabackup causes MySQL Server crash
Submitted:	16 May 2006 16:22	Modified:	17 May 2006 16:36
Reporter:	XINJIAN GUO	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S1 (Critical)
Version:	5.0.19	OS:	Linux (RHEL4 AS)
Assigned to:		CPU Architecture:	Any

Description:
MySQl Server 5.0.19 crashes when running mabackup of mysql-administrator-1.1.6-1 on our RHEL4 AS server.

How to repeat:
run mabackup or backup via MySQL-Administrator GUI on RHEL4 AS

Thank you for a problem report. Please, send the appropriate part of the error log.

Please, also try to repeat with a newer version of MySQL server, 5.0.21.

mysqld got signal 11;
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=8388600
read_buffer_size=131072
max_used_connections=1
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8a36e00
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...
Cannot determine thread, fp=0x42466c, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x815a810
0x908888
0x8155a44
0x8155a44
0x80ef785
0x814e6c0
0x81accb0
0x81a91a8
0x81a92ca
0x81a9613
0x81b7824
0x81b876c
0x81b8de5
0x816f94d
0x8175d2d
0x81764c1
0x8177294
0x8177920
0x902371
0x86d9be
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8a62978 = SELECT /*!40001 SQL_NO_CACHE */ * FROM `bugtest`.`t_feedback`
thd->thread_id=2
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

I got the same error when running MySQL Server 5.0.21.

And got the following output:
nm: /usr/sbin/mysqld: no symbols
when ran:
nm -n /usr/sbin/mysqld > /tmp/mysqld.sym

Will that statement:

SELECT /*!40001 SQL_NO_CACHE */ * FROM `bugtest`.`t_feedback`

produce the same crash when executed directly for mmysql command line client?

Please, send the SHOW CREATE TABLE and SHOW TABLE STATUS results for that `bugtest`.`t_feedback` table.

Yes, running that SELECT statement from mysql client also causes crash.

SHOW CREATE TABLE output:
 t_feedback | CREATE TABLE `t_feedback` (
  `respID` tinyint(3) NOT NULL auto_increment,
  `transmit_date` date NOT NULL default '0000-00-00',
  `transmit_src` varchar(255) NOT NULL default '',
  `i_ctype` int(2) NOT NULL default '0',
  `pfname` varchar(255) NOT NULL default '',
  `plname` varchar(255) NOT NULL default '',
  `pinstitution` varchar(255) NOT NULL default '',
  `pemail` varchar(255) NOT NULL default '',
  `pcomments` blob NOT NULL,
  PRIMARY KEY  (`respID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 

SHOW TABLE STATUS output:
| Name           | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time         | Update_time         | Check_time          | Collation         | Checksum | Create_options | Comment |
| t_feedback     | MyISAM | 7       | Dynamic    | 17   | 299            | 5096        | 4294967295      | 2048         | 0         | 18             | 2005-01-18 14:14:06 | 2006-02-15 05:46:25 | 2006-05-15 15:51:48 | latin1_swedish_ci | NULL     |                |         |

Please, run 

CHECK TABLE `t_feedback` FOR UPGRADE;

and then try to repeat the crash. Infortm about the results.

mysql> check table t_feedback for upgrade;
+--------------------+-------+----------+----------+
| Table              | Op    | Msg_type | Msg_text |
+--------------------+-------+----------+----------+
| bugtest.t_feedback | check | status   | OK       |
+--------------------+-------+----------+----------+
1 row in set (0.00 sec)

mysql> SELECT /*!40001 SQL_NO_CACHE */ * FROM `bugtest`.`t_feedback`;
ERROR 2013 (HY000): Lost connection to MySQL server during query

MySQL Server error log shows the same crash error as before.

Please, send the resolved stack trace of that crash.

mysqld got signal 11;
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=8388600
read_buffer_size=131072
max_used_connections=1
max_connections=100
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225791 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8a36e00
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...
Cannot determine thread, fp=0x14766c, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x815a810
0x908888
0x8155a44
0x8155a44
0x80ef785
0x814e6c0
0x81accb0
0x81a91a8
0x81a92ca
0x81a9613
0x81b7824
0x81b876c
0x81b8de5
0x816f94d
0x8175d2d
0x81764c1
0x8177294
0x8177920
0x902371
0x86d9be
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8a62978 = SELECT /*!40001 SQL_NO_CACHE */ * FROM `bugtest`.`t_feedback`
thd->thread_id=3
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

Please, _resolve_ that stack trace, as described in http://dev.mysql.com/doc/refman/5.0/en/using-stack-trace.html. 

Send also SHOW TABLE STATUS results for that table now, after you executed CHECK ... FOR UPGRADE.

I have difficulty resolving the stack trace because I can't find mysqld.sym.gz on my server to run 
  gunzip < bin/mysqld.sym.gz > /tmp/mysqld.sym
and when I ran
  nm -n libexec/mysqld > /tmp/mysqld.sym
I got 
   nm: 'libexec/mysqld': No such file
and when I ran
  nm -n /usr/sbin/mysqld > /tmp/mysqld.sym
I got
  nm: /usr/sbin/mysqld: no symbols

The output of SHOW TABLE STATUS:
| t_feedback     | MyISAM | 7       | Dynamic    | 17   | 299            | 5096        | 4294967295      | 2048         | 0         | 18             | 2005-01-18 14:14:06 | 2006-02-15 05:46:25 | 2006-05-15 15:51:48 | latin1_swedish_ci | NULL     |                |         |

I re-created the database instance "bugtest", the crash problem does not exist anymore when run the same SELECT query.