Pardon my ignorance, what "Linux table corruption" and what versions of
Linux and MySQL are we talking about? I googled, but came back only with
"188.8.131.52 Using myisamchk for Crash Recovery ... --skip-external-locking".
Not much help. I'm sorry if this is old news, but I thougth I was
following this and didn't notice any threads on it.
On Mon, 12 Aug 2002, Heikki Tuuri wrote:
> Date: Mon, 12 Aug 2002 20:52:14 +0300
> From: Heikki Tuuri <Heikki.Tuuri@stripped>
> To: mysql@stripped
> Subject: Re: Found cause of crash - simple SQL statement.
> the crash probably means the table is corrupt. That is a very basic query
> you run. Difficult to believe in any bug in SQL itself.
> Please dump your tables.
> Then upgrade to MySQL-Max-3.23.51. It is best to use an official binary.
> Then run CHECK TABLE on the table statcache. What does it print to the .err
> Then recreate the InnoDB database, data files and all, and import your
> tables back to it.
> Please test the query again then.
> There have been lots of bug fixes since 3.23.39. It is also possible that
> this is yet another case of Linux table corruption where the cause will
> never be found.
> Best regards,
> Innobase Oy
> See previous bug report
> Mysql crashes when executing simple query:
> mysql> delete from statcache where spamdate < 1028304682;
> ERROR 2013: Lost connection to MySQL server during query
> Table def:
> CREATE TABLE statcache (
> reportid int(10) unsigned NOT NULL default '0',
> spamid int(10) unsigned NOT NULL default '0',
> issueid int(10) unsigned NOT NULL default '0',
> recipid int(10) unsigned NOT NULL default '0',
> spamdate int(10) unsigned NOT NULL default '0',
> type tinyint(3) unsigned NOT NULL default '0',
> PRIMARY KEY (reportid),
> KEY date (spamdate),
> KEY dr (recipid,type,spamdate),
> KEY di (issueid,type,spamdate)
> ) TYPE=InnoDB;
> I can provide table contents if needed. I'll dump it now so we have a
> of the problematic data.
> 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
> the problem, but since we have already crashed, something is definitely
> and this may fail.
> It is possible that mysqld could use up to
> key_buffer_size + (record_buffer + sort_buffer)*max_connections = 802411 K
> bytes of memory
> Hope that's ok; if not, decrease some variables in the equation.
> 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=0xbfc7e2f8, backtrace may not be correct.
> Stack range sanity check OK, backtrace follows:
> 0x8071b58 + 134683480
> 0x825a668 + 136685160
> 0x81737bf + 135739327
> 0x816f5bd + 135722429
> 0x815960e + 135632398
> 0x812a29b + 135439003
> 0x8135131 + 135483697
> 0x8136142 + 135487810
> 0x8136332 + 135488306
> 0x8122a7d + 135408253
> 0x80c91ad + 135041453
> 0x80a6c41 + 134900801
> 0x807bad0 + 134724304
> 0x807d955 + 134732117
> 0x8078ed3 + 134713043
> 0x807ece1 + 134737121
> 0x80780ae + 134709422
> 0x8257c7c + 136674428
> 0x828d3ba + 136893370
> New value of fp=(nil) failed sanity check, terminating stack trace!
> Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow
> 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 0x84e8788 = delete from statcache where spamdate < 1028304682
> Successfully dumped variables, if you ran with --log, take a look at the
> details of what thread 806 did to cause the crash. In some cases of really
> bad corruption, the values shown above may be invalid.
> The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
> information that should help you find out what is causing the crash.
> Number of processes running now: 0
> See above.
> Still working on a workaround. Will have to set up a non-production server
> bang on.
> >Submitter-Id: <submitter ID>
> spamcop.net (Julian Haight)
> >MySQL support: licence
> >Synopsis: MySQL crashes on simple 'delete from' query
> >Severity: serious
> >Priority: medium
> >Category: mysql
> >Class: sw-bug
> >Release: mysql-3.23.39 (Source distribution)
> System: Linux sandyman 2.4.18 #8 SMP Thu Jul 18 18:24:01 EDT 2002 i686
> Architecture: i686
> Some paths: /usr/bin/perl /usr/bin/make /usr/bin/gmake /usr/bin/gcc
> GCC: Reading specs from /usr/lib/gcc-lib/i386-slackware-linux/2.95.3/specs
> gcc version 2.95.3 20010315 (release)
> Compilation info: CC='gcc' CFLAGS='' CXX='c++' CXXFLAGS='' LDFLAGS=''
> lrwxrwxrwx 1 root root 13 Mar 19 12:57 /lib/libc.so.6 ->
> -rwxr-xr-x 1 root root 4783716 May 25 2001 /lib/libc-2.2.3.so
> -rw-r--r-- 1 root root 24721042 May 25 2001 /usr/lib/libc.a
> -rw-r--r-- 1 root root 178 May 25 2001 /usr/lib/libc.so
> Configure command:
> ./configure --prefix=/usr --with-mysqld-user=mysql --with-unix-socket-path=
> --localstatedir=/var/lib/mysql --with-pthread --enable-thread-safe-client --
> --with-raid --with-libwrap --without-bench i386-slackware-linux
> Before posting, please check:
> http://www.mysql.com/manual.php (the manual)
> http://lists.mysql.com/ (the list archive)
> To request this thread, e-mail <mysql-thread116887@stripped>
> To unsubscribe, e-mail <mysql-unsubscribe-mussatto=csz.com@stripped>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
William Mussatto, Senior Systems Engineer
ph. 909-920-9154 ext. 27