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 "4.4.6.7 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 <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: Found cause of crash - simple SQL statement. > > Julian, > > 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 > log? > > 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, > > Heikki > Innobase Oy > > >Description: > 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 > snapshot > 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 > diagnose > the problem, but since we have already crashed, something is definitely > wrong > and this may fail. > > key_buffer_size=402649088 > record_buffer=2093056 > sort_buffer=2097144 > max_used_connections=50 > max_connections=100 > threads_connected=10 > 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. > > thd=0x8720c8a8 > 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 > 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 0x84e8788 = delete from statcache where spamdate < 1028304682 > thd->thread_id=806 > > 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 > > >How-To-Repeat: > See above. > >Fix: > Still working on a workaround. Will have to set up a non-production server > to > bang on. > > >Submitter-Id: <submitter ID> > >Originator: > >Organization: > 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) > > >Environment: > > System: Linux sandyman 2.4.18 #8 SMP Thu Jul 18 18:24:01 EDT 2002 i686 > unknown > 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/i386-slackware-linux/2.95.3/specs > gcc version 2.95.3 20010315 (release) > Compilation info: CC='gcc' CFLAGS='' CXX='c++' CXXFLAGS='' LDFLAGS='' > LIBC: > lrwxrwxrwx 1 root root 13 Mar 19 12:57 /lib/libc.so.6 -> > libc-2.2.3.so > -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= > /var/run/mysql/mysql.sock > --localstatedir=/var/lib/mysql --with-pthread --enable-thread-safe-client -- > enable-assembler > --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 <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > Sincerely, William Mussatto, Senior Systems Engineer CyberStrategies, Inc ph. 909-920-9154 ext. 27 --------------------------------------------------------------------- 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 <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
