Description:
Running mysqldump with options '-h servername -u username --allow-keywords --quote-names -p"password" --opt dbname' causes "mysqldump: Can't get CREATE TABLE for table `F_Actionshelp` (Lost connection to MySQL server during query)"
F_Actionshelp is the first table in the db, which was (and always has been since it was added) an empty/unused table at the time, and has the following format:
CREATE TABLE `F_Actionshelp` (
`Action` varchar(25) NOT NULL default '',
`Title` varchar(255) NOT NULL default '',
`Content` text NOT NULL,
PRIMARY KEY (`Action`)
) TYPE=InnoDB;
executing "SHOW CREATE TABLE `F_Actionshelp`" through phpMyAdmin does not cause the crash
client running binary release mysql-standard-4.0.21-pc-linux-i686 connecting to server running the same binary release.
reported error in logfile is:
Version: '4.0.21-standard-log' socket: '/tmp/mysql.sock' port: 3306 Official MySQL-standard binary
InnoDB: Error: select_lock_type is 99999999 inside ::start_stmt()!
041019 4:41:52InnoDB: Assertion failure in thread 4980748 in file ha_innodb.cc line 4581
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. See section 6.1 of
InnoDB: http://www.innodb.com/ibman.php about forcing recovery.
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=335544320
read_buffer_size=4190208
max_used_connections=87
max_connections=200
threads_connected=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1965278 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x88ab8f0
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=0xbfe3eef8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8070c40
0x8261678
0x80cf2dc
0x808feb8
0x808ff73
0x80dca24
0x807c983
0x807f3aa
0x807ab13
0x807a56d
0x8079da9
0x825ee2c
0x82948ea
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/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 0x8becea8 = show create table `F_Actionshelp`
thd->thread_id=76404
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.
Number of processes running now: 0
041019 04:41:52 mysqld restarted
041019 4:41:52 Warning: Asked for 196608 thread stack, but got 126976
041019 4:41:52 Can't start server: Bind on TCP/IP port: Address already in use
041019 4:41:52 Do you already have another mysqld server running on port: 3306 ?
041019 4:41:52 Aborting
041019 4:41:52 /usr/local/mysql/bin/mysqld: Shutdown Complete
041019 04:41:52 mysqld ended
stacktrace resolved:
0x8070c40 handle_segfault + 420
0x8261678 pthread_sighandler + 184
0x80cf2dc start_stmt__11ha_innobaseP3THD + 336
0x808feb8 check_lock_and_start_stmt__FP3THDP8st_table13thr_lock_type + 84
0x808ff73 open_ltable__FP3THDP13st_table_list13thr_lock_type + 143
0x80dca24 mysqld_show_create__FP3THDP13st_table_list + 36
0x807c983 mysql_execute_command__Fv + 4959
0x807f3aa mysql_parse__FP3THDPcUi + 146
0x807ab13 dispatch_command__F19enum_server_commandP3THDPcUi + 1435
0x807a56d do_command__FP3THD + 157
0x8079da9 handle_one_connection + 641
0x825ee2c pthread_start_thread + 220
0x82948ea thread_start + 4
dropping and recreating the table did not fix the problem.
Downgrading to mysql-max-4.0.20 fixed the problem, so i assume this is something related to 4.0.21
I did not test if the problem also occured when running mysqldump on the db machine itself.
If you need more info let me know.
How to repeat:
i repeated the mysqldump several times to test if it crashed at the same point continuously. This was the case.
Not sure if this will really repeat itself in a different environment, but i would assume:
-Run mysql-standard-4.0.21 on Linux (Glibc-2.3.2)
-Create an empty table with format specified under 'Description'.
-run mysqldump on it (from a remote machine?)
