200108 21:09:53 mysqld restarted 200108 21:09:53 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295 200108 21:09:53 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295 InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! 200108 21:09:53 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... 200108 21:09:53 InnoDB: Error: page 31829 log sequence number 1 2455623301 InnoDB: is in the future! Current system log sequence number 0 383649413. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: for more information. 200108 21:09:53 InnoDB: Started; log sequence number 0 383649413 200108 21:09:53 [Note] /usr/local/mysql/libexec/mysqld: ready for connections. Version: '5.0.67' socket: '/tmp/mysql.sock' port: 3306 Source distribution 200108 21:10:02InnoDB: Assertion failure in thread 196619 in file trx0undo.c line 515 InnoDB: Failing assertion: free + TRX_UNDO_LOG_XA_HDR_SIZE < UNIV_PAGE_SIZE - 100 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. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. 200108 21:10:02 - 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=1048576 read_buffer_size=524288 max_used_connections=1 max_connections=300 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 231424 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa99b1a0 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=0xbe1fcc88, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8168b09 0x82ecfe8 0xb7513c18 0x82edc0a 0x82eb14a 0x82de94c 0x82d1fda 0x82cb94b 0x82cbf00 0x82b4a2c 0x82b39be 0x82b32d8 0x82b270e 0x82a0f58 0x821ccc4 0x81d84f6 0x817eaeb 0x81849bf 0x817c96d 0x8187fa9 0x817bbac 0xb77346de 0xb75c0bc7 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 0xa9e8b08 = update cnv_table_versions set latest_version = 14937, oldest_version = 853 where mysterious_id = 1 and table_name = 'trm_in_class if' thd->thread_id=2 The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 0 200108 21:10:02 mysqld restarted 200108 21:10:02 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295 200108 21:10:02 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295 InnoDB: The log sequence number in ibdata files does not match InnoDB: the log sequence number in the ib_logfiles! 200108 21:10:03 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... 200108 21:10:03 InnoDB: Error: page 31829 log sequence number 1 2455623301 InnoDB: is in the future! Current system log sequence number 0 383649413. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: for more information. 200108 21:10:03 InnoDB: Started; log sequence number 0 383649413 200108 21:10:03 [Note] /usr/local/mysql/libexec/mysqld: ready for connections. Version: '5.0.67' socket: '/tmp/mysql.sock' port: 3306 Source distribution 200108 21:10:24InnoDB: Assertion failure in thread 196619 in file trx0undo.c line 515 InnoDB: Failing assertion: free + TRX_UNDO_LOG_XA_HDR_SIZE < UNIV_PAGE_SIZE - 100 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. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. 200108 21:10:24 - 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=1048576 read_buffer_size=524288 max_used_connections=1 max_connections=300 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 231424 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8ec11a0 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=0xbdffcc88, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8168b09 0x82ecfe8 0xb7563c18 0x82edc0a 0x82eb14a 0x82de94c 0x82d1fda 0x82cb94b 0x82cbf00 0x82b4a2c 0x82b39be 0x82b32d8 0x82b270e 0x82a0f58 0x821ccc4 0x81d84f6 0x817eaeb 0x81849bf 0x817c96d 0x8187fa9 0x817bbac 0xb77846de 0xb7610bc7 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 0x8f0eb08 = update cnv_table_versions set latest_version = 14937, oldest_version = 853 where mysterious_id = 1 and table_name = 'trm_in_class if' thd->thread_id=2 The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 0 200108 21:10:24 mysqld restarted