MySQL Bugs: #5530: mysqldump connection lost

Bug #5530	mysqldump connection lost
Submitted:	12 Sep 2004 3:09	Modified:	28 Oct 2004 12:39
Reporter:	Bernardo Innocenti	Email Updates:
Status:	Duplicate	Impact on me:	None
Category:	MySQL Server: mysqldump Command-line Client	Severity:	S1 (Critical)
Version:	4.0.21	OS:	Linux (Linux)
Assigned to:		CPU Architecture:	Any

Description:
After upgrading from 4.0.21 to 4.0.21, the following 
command doesn't work any more: 
 
# mysqldump -u root --password=XXX --opt --no-create-info --complete-insert fm user 
user_group 
-- MySQL dump 9.11 
-- 
-- Host: localhost    Database: fm 
-- ------------------------------------------------------ 
-- Server version       4.0.21-standard 
mysqldump: Can't get info about table: `user` 
error: Lost connection to MySQL server during query 
 
 
No errors appear in mysql.log. These are the last lines of 
output produced by strace on the above command: 
 
write(1, "-- Server version\t4.0.21-standard\n", 34-- Server version    4.0.21-standard 
) = 34 
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK)  = 0 
read(3, 0x40000008, 1047551)            = -1 EAGAIN (Resource temporarily unavailable) 
fcntl64(3, F_SETFL, O_RDWR)             = 0 
write(3, "\3\0\0\0\2fm", 7)             = 7 
read(3, "\5\0\0\1", 4)                  = 4 
read(3, "\0\0\0\2\0", 5)                = 5 
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK)  = 0 
read(3, 0x40000008, 1047551)            = -1 EAGAIN (Resource temporarily unavailable) 
fcntl64(3, F_SETFL, O_RDWR)             = 0 
write(3, "N\0\0\0\3LOCK TABLES `user` READ /*!32311 LOCAL */,`user_group` 
READ /*!32311 LOCAL */", 82) = 82 
read(3, "\5\0\0\1", 4)                  = 4 
read(3, "\0\0\0\2\0", 5)                = 5 
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK)  = 0 
read(3, 0x40000008, 1047551)            = -1 EAGAIN (Resource temporarily unavailable) 
fcntl64(3, F_SETFL, O_RDWR)             = 0 
write(3, "#\0\0\0\3SET OPTION SQL_QUOTE_SHOW_CREATE=0", 39) = 39 
read(3, "\5\0\0\1", 4)                  = 4 
read(3, "\0\0\0\2\0", 5)                = 5 
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK)  = 0 
read(3, 0x40000008, 1047551)            = -1 EAGAIN (Resource temporarily unavailable) 
fcntl64(3, F_SETFL, O_RDWR)             = 0 
write(3, "\30\0\0\0\3show fields from `user`", 28) = 28 
read(3, "", 4)                          = 0 
read(3, "", 4)                          = 0 
shutdown(3, 2 /* send and receive */)   = 0 
close(3)                                = 0 
munmap(0x40000000, 1048576)             = 0 
write(2, "mysqldump: Can\'t get info about table: `user`\nerror: Lost connection to 
MySQL server during query\n", 98mysqldump: Can't get info about table: `user` 
error: Lost connection to MySQL server during query 
) = 98 
munmap(0x40100000, 4096)                = 0 
_exit(2)                                = ? 
 

How to repeat:
I'm not sure if the bug is caused by something in my table 
structure, because I had to quickly revert the production 
machine to 4.0.20. 
 
I'd be glad to provide additional information if needed.

Is it bug in the server or in the client ?
That is, if you use mysqldump from 4.0.21 and the server from 4.0.20 - do you get the error ? And if it's 4.0.21 server and 4.0.20 mysqldump ?

It's most certainly a server bug. I've fixed it by only
reverting the MySQL-server RPM package to 4.0.20.

From the strace log it looks like the socket gets closed by the
server before replying to the last query.  The server doesn't
crash: it's still up and healty after the fact.

encountering the same problem on my windows XP, I must say that my server does crash because of this. I must manually restart it afterwards.
Problem idd solved by reverting to 4.0.20d

Also hit this bug. This happens if you have InnoDB tables and using --lock-tables or --opt option for mysldump.

And i forgot, this is from error log:

InnoDB: Error: select_lock_type is 99999999 inside ::start_stmt()!
041028 11:24:16InnoDB: Assertion failure in thread 147466 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=8388600
read_buffer_size=131072
max_used_connections=0
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=0x882d8c0
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...
frame pointer (ebp) is NULL, did you compile with
-fomit-frame-pointer? Aborting backtrace!
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x882fab8 = show create table `adresy`
thd->thread_id=1
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.

This is a duplicate of bug #5538, which has been fixed in 4.0.22 (which should be released very soon). I'm sorry for not noticing this bug report earlier.

Hi!

This bug never got to the 4.1 series.

Regards,

Heikki