Bug #6249 InnoDB engine crash on MySQL 4.0.21 when dumping database
Submitted: 25 Oct 2004 18:30 Modified: 30 Oct 2004 7:29
Reporter: Henno Schooljan Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S3 (Non-critical)
Version:4.0.21 OS:Linux (Linux (Gentoo))
Assigned to: CPU Architecture:Any

[25 Oct 2004 18:30] Henno Schooljan
Description:
When dumping a database with InnoDB tables, the InnoDB engine crashes. This is the result:

$ mysqldump --opt -v -uarrowtest -pthepassword artest_site > arrow2.SQL
-- Connecting to localhost...
-- Retrieving table structure for table applications...
mysqldump: Can't get CREATE TABLE for table `applications` (Lost connection to MySQL server during query)

The database automatically restarts and does its recovery routine. Reverting to version 4.0.20 using the same configuration and build time compiler flags solves the problem again, so I suspect it is a bug introduced in 4.0.21. The database is checked and dumped/imported several times, no errors there.
-----------------------------------------

The following is being logged in the error log when the error occurs:

-----------------------------------------

InnoDB: Error: select_lock_type is 99999999 inside ::start_stmt()!
041025 20:10:41InnoDB: Assertion failure in thread 278539 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=16777216
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 = 233983 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x88df7f0
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=0x296c8cf8, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x810fd35
0x25aae613
0x817fd5a
0x812fea6
0x819068f
0x811ecc9
0x8121cf2
0x811c5b0
0x811c0cb
0x811b995
0x25aa8fc8
0x25cef12a
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 0x88f1268 = show create table `applications`
thd->thread_id=8
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.
Writing a core file
041025 20:10:41  InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 1261610815
InnoDB: Doing recovery: scanned up to log sequence number 0 1261610815
041025 20:10:41  InnoDB: Flushing modified pages from the buffer pool...
041025 20:10:41  InnoDB: Started
/usr/sbin/mysqld: ready for connections.
Version: '4.0.21'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Gentoo Linux mysql-4.0.21

-----------------------------------------

Some extra information:

>Release:       mysql-4.0.21 (Gentoo Linux mysql-4.0.21)

>C compiler:    gcc (GCC) 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)
>C++ compiler:  g++ (GCC) 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)
>Environment:
        <machine, os, target, libraries (multiple lines)>
System: Linux sfynx 2.4.27-sfynx #6 Sun Sep 26 01:56:41 CEST 2004 i686 AMD Athlon(TM) XP1700+ AuthenticAMD GNU/Linux
Architecture: i686

Some paths:  /usr/bin/perl /usr/bin/make /usr/bin/gmake /usr/bin/gcc /usr/bin/cc
GCC: Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs
Configured with: /usr/portage/temp/portage/gcc-3.3.4-r1/work/gcc-3.3.4/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3 --includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info --enable-shared --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib --enable-languages=c,c++ --enable-threads=posix --enable-long-long --disable-checking --disable-libunwind-exceptions --enable-cstdio=stdio --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --disable-nls --disable-multilib --enable-__cxa_atexit --enable-clocale=generic
Thread model: posix
gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)
Compilation info: CC='gcc'  CFLAGS='-march=athlon-xp -O3 -pipe -DHAVE_ERRNO_AS_DEFINE=1 -DUSE_OLD_FUNCTIONS'  CXX='g++'  CXXFLAGS='-march=athlon-xp -O3 -pipe -felide-constructors -fno-exceptions -fno-rtti'  LDFLAGS=''  ASFLAGS=''
LIBC:
lrwxrwxrwx  1 root root 13 Aug 18 00:08 /lib/libc.so.6 -> libc-2.3.3.so
-rwxr-xr-x  1 root root 1174488 Aug 18 00:08 /lib/libc-2.3.3.so
-rw-r--r--  1 root root 2594492 Aug 18 00:08 /usr/lib/libc.a
-rwxr-xr-x  1 root root 204 Aug 18 00:08 /usr/lib/libc.so
Configure command: ./configure '--prefix=/usr' '--host=i686-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--libexecdir=/usr/sbin' '--sysconfdir=/etc/mysql' '--localstatedir=/var/lib/mysql' '--with-raid' '--with-low-memory' '--enable-assembler' '--with-charset=latin1' '--enable-local-infile' '--with-mysqld-user=mysql' '--with-extra-charsets=all' '--enable-thread-safe-client' '--with-client-ldflags=-lstdc++' '--with-comment=Gentoo Linux mysql-4.0.21' '--with-unix-socket-path=/var/run/mysqld/mysqld.sock' '--with-embedded-server' '--with-berkeley-db=./bdb' '--without-readline' '--enable-shared' '--enable-static' '--with-libwrap' '--with-innodb' '--with-vio' '--with-openssl' '--without-debug' 'CC=gcc' 'CFLAGS=-march=athlon-xp -O3 -pipe -DHAVE_ERRNO_AS_DEFINE=1 -DUSE_OLD_FUNCTIONS' 'CXXFLAGS=-march=athlon-xp -O3 -pipe -felide-constructors -fno-exceptions -fno-rtti' 'CXX=g++' 'host_alias=i686-pc-linux-gnu'

How to repeat:
Dump a database with InnoDB tables with mysqldump --opt -v -u<user> -p<password> <database> > file.SQL

Suggested fix:
Did not find any fix, had to return to 4.0.20 again.
[25 Oct 2004 19:08] Henno Schooljan
There already was a bug report about this (#5538), strange I did not find it earlier with the search. Please close this one.
[25 Oct 2004 19:16] MySQL Verification Team
Hi,

Thank you for the report. This is duplicate of the bug report #5538
http://bugs.mysql.com/5538
[30 Oct 2004 7:29] Heikki Tuuri
Fixed in 4.0.22.