061203 23:41:59 mysqld started 061203 23:41:59 [Warning] Although a path was specified for the --log option, log tables are used. To enable logging to file use the --log-output option. 061203 23:41:59 [Warning] Although a path was specified for the --log-slow-queries option, log tables are used. To enable logging to file use the --log-output option. InnoDB: The first specified data file ./ibdata1 did not exist: InnoDB: a new database to be created! 061203 23:41:59 InnoDB: Setting file ./ibdata1 size to 10 MB InnoDB: Database physically writes the file full: wait... 061203 23:41:59 InnoDB: Log file ./ib_logfile0 did not exist: new to be created InnoDB: Setting log file ./ib_logfile0 size to 5 MB InnoDB: Database physically writes the file full: wait... 061203 23:41:59 InnoDB: Log file ./ib_logfile1 did not exist: new to be created InnoDB: Setting log file ./ib_logfile1 size to 5 MB InnoDB: Database physically writes the file full: wait... InnoDB: Doublewrite buffer not found: creating new InnoDB: Doublewrite buffer created InnoDB: Creating foreign key constraint system tables InnoDB: Foreign key constraint system tables created 061203 23:42:00 InnoDB: Started; log sequence number 0 0 061203 23:42:00 [Note] /opt/mysql/mysql-5.1.14/libexec/mysqld: ready for connections. Version: '5.1.14-beta-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution 061203 23:42:00 [Note] SCHEDULER: Loaded 0 events 061204 2:58:37 [Note] /opt/mysql/mysql-5.1.14/libexec/mysqld: Normal shutdown 061204 2:58:37 [Note] SCHEDULER: Purging queue. 0 events 061204 2:58:37 InnoDB: Starting shutdown... 061204 2:58:38 InnoDB: Shutdown completed; log sequence number 0 46409 061204 2:58:38 [Note] /opt/mysql/mysql-5.1.14/libexec/mysqld: Shutdown complete 061204 02:58:38 mysqld ended 061204 13:41:33 InnoDB: Started; log sequence number 0 46409 061204 13:41:38 [Note] Starting MySQL Cluster Binlog Thread 061204 13:41:38 [Note] ../mysql/libexec/mysqld: ready for connections. Version: '5.1.14-beta-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution 061204 13:41:38 [Note] SCHEDULER: Loaded 0 events 061204 17:50:10 [Note] ../mysql/libexec/mysqld: Normal shutdown 061204 17:50:10 [Note] SCHEDULER: Purging queue. 0 events 061204 17:50:10 [Note] Stopping Cluster Utility thread 061204 17:50:10 [Note] Stopping Cluster Binlog 2006-12-04 17:50:13 [NdbApi] INFO -- Management server closed connection early. It is probably being shut down (or has problems). We will retry the connection. 061204 17:50:10 InnoDB: Starting shutdown... 061204 17:50:11 InnoDB: Shutdown completed; log sequence number 0 46409 061204 17:50:13 [Note] ../mysql/libexec/mysqld: Shutdown complete 061205 9:51:56 InnoDB: Started; log sequence number 0 46409 061205 9:52:06 [Note] Starting MySQL Cluster Binlog Thread 061205 9:52:07 [Note] ../mysql/libexec/mysqld: ready for connections. Version: '5.1.14-beta-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution 061205 9:52:07 [Note] SCHEDULER: Loaded 0 events 061205 10:05:25 [ERROR] Got error 233 when reading table './world_ndb_dd/nationaldish' 061205 11:24:34 [Note] ../mysql/libexec/mysqld: Normal shutdown 061205 11:24:34 [Note] SCHEDULER: Purging queue. 0 events 061205 11:24:34 [Note] Stopping Cluster Binlog 061205 11:24:34 [Note] Stopping Cluster Utility thread 061205 11:24:34 InnoDB: Starting shutdown... 061205 11:24:37 InnoDB: Shutdown completed; log sequence number 0 46409 061205 11:24:38 [Note] ../mysql/libexec/mysqld: Shutdown complete 061205 11:32:26 InnoDB: Started; log sequence number 0 46409 061205 11:32:26 [Note] Starting MySQL Cluster Binlog Thread 061205 11:32:26 [Note] ../mysql/libexec/mysqld: ready for connections. Version: '5.1.14-beta-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution 061205 11:32:26 [Note] SCHEDULER: Loaded 0 events 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=8388600 read_buffer_size=131072 max_used_connections=1 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 = 225791 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x8d2cb98 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=0xb4fbf6f8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8218d13 0x82f48f7 Stack trace seems successful - bottom reached 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 0x8d59ac8 = CREATE UNIQUE INDEX CountryCodeDishMembers ON NationalDish (CountryCode,calories) using hash thd->thread_id=2 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 061205 11:34:31 InnoDB: Started; log sequence number 0 46409 061205 11:34:31 [Note] Starting MySQL Cluster Binlog Thread ../mysql/libexec/mysqld: Table 'general_log' is marked as crashed and should be repaired ../mysql/libexec/mysqld: Table 'slow_log' is marked as crashed and should be repaired 061205 11:34:32 [Note] Recovering after a crash using mysql-bin 061205 11:34:32 [Note] Starting crash recovery... 061205 11:34:32 [Note] Crash recovery finished. 061205 11:34:32 [Note] ../mysql/libexec/mysqld: ready for connections. Version: '5.1.14-beta-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution 061205 11:34:32 [Note] SCHEDULER: Loaded 0 events 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=8388600 read_buffer_size=131072 max_used_connections=1 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 = 225791 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x8d2d9c8 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=0xb4f9a6f8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8218d13 0x82f48f7 0x8305932 0x8313418 0x82f2424 0x82f3194 0x82f32e1 0x8336579 0x823b4af 0x823e558 0x823eb00 0x8240a36 0xb7ee5504 0xb7e0e51e 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 0x8d5a910 = CREATE UNIQUE INDEX CountryCodeDishMembers ON NationalDish (CountryCode,calories) using hash thd->thread_id=2 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 061205 11:42:05 InnoDB: Started; log sequence number 0 46409 061205 11:42:06 [Note] Starting MySQL Cluster Binlog Thread ../mysql/libexec/mysqld: Table 'general_log' is marked as crashed and should be repaired ../mysql/libexec/mysqld: Table 'slow_log' is marked as crashed and should be repaired 061205 11:42:06 [Note] Recovering after a crash using mysql-bin 061205 11:42:06 [Note] Starting crash recovery... 061205 11:42:06 [Note] Crash recovery finished. 061205 11:42:06 [Note] ../mysql/libexec/mysqld: ready for connections. Version: '5.1.14-beta-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution 061205 11:42:06 [Note] SCHEDULER: Loaded 0 events 061205 12:07:07 [Note] ../mysql/libexec/mysqld: Normal shutdown 061205 12:07:07 [Note] SCHEDULER: Purging queue. 0 events 061205 12:07:07 [Note] Stopping Cluster Utility thread 061205 12:07:08 [Note] Stopping Cluster Binlog 061205 12:07:08 InnoDB: Starting shutdown... 061205 12:07:11 InnoDB: Shutdown completed; log sequence number 0 46409 061205 12:07:11 [Note] ../mysql/libexec/mysqld: Shutdown complete 061205 12:49:18 InnoDB: Started; log sequence number 0 46409 061205 12:49:19 [Note] Starting MySQL Cluster Binlog Thread 061205 12:49:19 [Note] ../mysql/libexec/mysqld: ready for connections. Version: '5.1.14-beta-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution 061205 12:49:19 [Note] SCHEDULER: Loaded 0 events 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=8388600 read_buffer_size=131072 max_used_connections=1 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 = 225791 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x8d2a8e8 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=0xb503d6f8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8218d13 0x82f48f7 0x8305932 0x8313418 0x82f2424 0x82f3194 0x82f32e1 0x8336579 Stack trace seems successful - bottom reached 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 0x8d10428 = CREATE UNIQUE INDEX CountryCodeDishMembers ON NationalDish (CountryCode,calories) using hash thd->thread_id=2 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 061205 13:57:21 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... 061205 13:57:21 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 46419. InnoDB: Doing recovery: scanned up to log sequence number 0 46419 061205 13:57:21 InnoDB: Started; log sequence number 0 46419 061205 13:57:21 [Note] Starting MySQL Cluster Binlog Thread ../mysql/libexec/mysqld: Table 'general_log' is marked as crashed and should be repaired ../mysql/libexec/mysqld: Table 'slow_log' is marked as crashed and should be repaired 061205 13:57:21 [Note] Recovering after a crash using mysql-bin 061205 13:57:21 [Note] Starting crash recovery... 061205 13:57:21 [Note] Crash recovery finished. 061205 13:57:21 [Note] ../mysql/libexec/mysqld: ready for connections. Version: '5.1.14-beta-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution 061205 13:57:21 [Note] SCHEDULER: Loaded 0 events 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=8388600 read_buffer_size=131072 max_used_connections=1 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 = 225791 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x8d2d9f0 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=0xb50666f8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8218d13 0x82f48f7 0x8305932 0x8313418 0x82f2424 0x82f3194 0x82f32e1 0x8336579 0x823b4af 0x823e558 0x823eb00 0x8240a36 0xb7f81504 0xb7eaa51e 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 0x8d5a7f8 = CREATE UNIQUE INDEX CountryCodeDishMembers ON NationalDish (CountryCode,calories) using hash thd->thread_id=2 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 061205 14:00:34 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... 061205 14:00:34 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 46419. InnoDB: Doing recovery: scanned up to log sequence number 0 46419 061205 14:00:34 InnoDB: Started; log sequence number 0 46419 061205 14:00:34 [Note] Starting MySQL Cluster Binlog Thread ../mysql/libexec/mysqld: Table 'general_log' is marked as crashed and should be repaired ../mysql/libexec/mysqld: Table 'slow_log' is marked as crashed and should be repaired 061205 14:00:35 [Note] Recovering after a crash using mysql-bin 061205 14:00:35 [Note] Starting crash recovery... 061205 14:00:35 [Note] Crash recovery finished. 061205 14:00:35 [Note] ../mysql/libexec/mysqld: ready for connections. Version: '5.1.14-beta-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution 061205 14:00:35 [Note] SCHEDULER: Loaded 0 events 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=8388600 read_buffer_size=131072 max_used_connections=1 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 = 225791 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd: 0x8d2d9e8 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=0xb500f6f8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8218d13 0x82f48f7 Stack trace seems successful - bottom reached 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 0x8d5a7f0 = CREATE UNIQUE INDEX CountryCodeDishMembers ON NationalDish (CountryCode,calories) using hash thd->thread_id=3 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 061205 14:07:39 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... 061205 14:07:39 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 46419. InnoDB: Doing recovery: scanned up to log sequence number 0 46419 061205 14:07:39 InnoDB: Started; log sequence number 0 46419 061205 14:07:39 [Note] Starting MySQL Cluster Binlog Thread ../mysql/libexec/mysqld: Table 'general_log' is marked as crashed and should be repaired ../mysql/libexec/mysqld: Table 'slow_log' is marked as crashed and should be repaired 061205 14:07:40 [Note] Recovering after a crash using mysql-bin 061205 14:07:40 [Note] Starting crash recovery... 061205 14:07:40 [Note] Crash recovery finished. 061205 14:07:40 [Note] ../mysql/libexec/mysqld: ready for connections. Version: '5.1.14-beta-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution 061205 14:07:40 [Note] SCHEDULER: Loaded 0 events