Hello.
See: http://dev.mysql.com/doc/mysql/en/crashing.html Marten Lehmann <[EMAIL PROTECTED]> wrote: >> MySQL could die during your query. What is in error log? > > Oh my god, it's really dieing. I haven't looked in the error log before, > because I though, it's just this connection that got lost. This is the > error-log output: > > 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=402653184 > read_buffer_size=2093056 > max_used_connections=24 > max_connections=1000 > threads_connected=2 > It is possible that mysqld could use up to > key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections > = 290904 K > bytes of memory > Hope that's ok; if not, decrease some variables in the equation. > > thd=0xa3500490 > 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=0xbe5fe748, backtrace may not be correct. > Stack range sanity check OK, backtrace follows: > 0x80b2589 > 0x82cb328 > 0x808f73b > 0x808ce7e > 0x80db3d5 > 0x80ca97b > 0x80c45e1 > 0x80c4226 > 0x80c3a1d > 0x82c6c21 > 0x82f916a > New value of fp=(nil) failed sanity check, terminating stack trace! > Please read http://dev.mysql.com/doc/mysql/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 0xa68e960 = purge master logs before (select > adddate(current_timestamp(), interval -4 day)) > thd->thread_id=106601 > 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 > 050428 21:44:17 mysqld restarted > 050428 21:44:17 InnoDB: Database was not shut down normally! > InnoDB: Starting crash recovery. > InnoDB: Reading tablespace information from the .ibd files... > InnoDB: Restoring possible half-written data pages from the doublewrite > InnoDB: buffer... > 050428 21:44:18 InnoDB: Starting log scan based on checkpoint at > InnoDB: log sequence number 0 1226476. > InnoDB: Doing recovery: scanned up to log sequence number 0 1226476 > InnoDB: Last MySQL binlog file position 0 79, file name ./vm23-bin.000102 > 050428 21:44:18 InnoDB: Flushing modified pages from the buffer pool... > 050428 21:44:18 InnoDB: Started; log sequence number 0 1226476 > /usr/mysql/mysql-4.1.11/libexec/mysqld: ready for connections. > Version: '4.1.11-log' socket: '/tmp/mysql.sock' port: 3306 Source > distribution > > Regards > Marten > -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.NET http://www.ensita.net/ __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Gleb Paharenko / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET <___/ www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
