050824 14:46:04 mysqld started 050824 14:46:05 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=trxfw-bin' to avoid this problem. 050824 14:46:05 InnoDB: Started; log sequence number 0 24260373 050824 14:46:06 [Note] /usr/local/mysql/libexec/mysqld: ready for connections. Version: '5.0.11-beta-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution 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=268435456 read_buffer_size=1044480 max_used_connections=22 max_connections=800 threads_connected=11 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1897337 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x52276020 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=0x52519c48, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8146f4c 0x400517ce 0x42074d8e 0x42075bcc 0x81887e6 0x8185cd8 0x8219980 0x8186548 0x818233a 0x815a1a5 0x816095e 0x8158a10 0x815856d 0x8157ace 0x4004c881 0x420e40c7 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 0x522813d8 is invalid pointer thd->thread_id=4597 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 050824 15:35:00 mysqld restarted 050824 15:35:00 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=trxfw-bin' to avoid this problem. 050824 15:35:00 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... 050824 15:35:01 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 24260383. InnoDB: Doing recovery: scanned up to log sequence number 0 24260383 InnoDB: Last MySQL binlog file position 0 321806, file name ./trxfw-bin.000377 050824 15:35:01 InnoDB: Started; log sequence number 0 24260383 050824 15:35:01 [Note] Recovering after a crash using trxfw-bin 050824 15:35:01 [Note] Starting crash recovery... 050824 15:35:01 [Note] Crash recovery finished. 050824 15:35:01 [Note] /usr/local/mysql/libexec/mysqld: ready for connections. Version: '5.0.11-beta-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution 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=268435456 read_buffer_size=1044480 max_used_connections=25 max_connections=800 threads_connected=16 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1897337 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x5271fa98 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=0x52292c48, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8146f4c 0x400517ce 0x42074d8e 0x42075bcc 0x81887e6 0x8185cd8 0x8219980 0x8186548 0x818233a 0x815a1a5 0x816095e 0x8158a10 0x815856d 0x8157ace 0x4004c881 0x420e40c7 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 0x5239f378 is invalid pointer thd->thread_id=21536 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 050825 05:42:30 mysqld restarted 050825 5:42:30 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=trxfw-bin' to avoid this problem. 050825 5:42:30 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... 050825 5:42:30 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 24260393. InnoDB: Doing recovery: scanned up to log sequence number 0 24260393 InnoDB: Last MySQL binlog file position 0 321806, file name ./trxfw-bin.000377 050825 5:42:30 InnoDB: Started; log sequence number 0 24260393 050825 5:42:31 [Note] Recovering after a crash using trxfw-bin 050825 5:42:31 [Note] Starting crash recovery... 050825 5:42:31 [Note] Crash recovery finished. 050825 5:42:31 [Note] /usr/local/mysql/libexec/mysqld: ready for connections. Version: '5.0.11-beta-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution 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=268435456 read_buffer_size=1044480 max_used_connections=20 max_connections=800 threads_connected=12 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1897337 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x5270f880 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=0x5232fc48, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8146f4c 0x400517ce 0x42074d8e 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 0x8a5e638 = SELECT `Bay Schedule Table`.`IN_NUM` ,`Bay Schedule Table`.`BAY` ,`Bay Schedule Table`.`POSITION` ,`Bay Schedule Table`.`IN_DATE` ,`Bay Schedule Table`.`OUT_DATE` ,`Bay Schedule Table`.`DELAY_DAYS` ,`Derunit`.`DERRICK_DUE_DATE` ,`Bay Schedule Table`.`DK_NUM` ,`Derunit`.`MODEL` ,`Derunit`.`LINE` ,SUM(`Bay Schedule Table`.`HOURS_WORKED` ) ,COUNT(`Bay Schedule Table`.`HOURS_WORKED` ) FROM `Derunit`,`Bay Schedule Table` WHERE (((`Bay Schedule Table`.`DK_NUM` = `Derunit`.`UNIT` ) AND (`Bay Schedule Table`.`IN_NUM` = `Derunit`.`INSTALLATION_ORDER_NUMBER` ) ) AND ((`Bay Schedule Table`.`IN_UNIT_MTH` = 'AUGUST' ) AND (`Bay Schedule Table`.`IN_UNIT_YEAR` = 2005 ) ) ) GROUP BY `Bay Schedule Table`.`IN_NUM` ,`Bay Schedule Table`.`BAY` ,`Bay Schedule Table`.`POSITION` ,`Bay Schedule Table`.`IN_DATE` ,`Bay Schedule Table`.`OUT_DATE` ,`Bay Schedule Table`.`DELAY_DAYS` ,`Derunit`.`DERRICK_DUE_DATE` ,`Bay Schedule Table`.`DK_NUM` ,`Derunit`.`MODEL` ,`Derunit`.`LINE` ORDER BY `Bay Schedule Table`.`BAY` ,`Bay Schedule Tab thd->thread_id=3246 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 050825 07:01:46 mysqld restarted 050825 7:01:46 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=trxfw-bin' to avoid this problem. 050825 7:01:46 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... 050825 7:01:47 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 24260393. InnoDB: Doing recovery: scanned up to log sequence number 0 24260393 InnoDB: Last MySQL binlog file position 0 321806, file name ./trxfw-bin.000377 050825 7:01:47 InnoDB: Started; log sequence number 0 24260393 050825 7:01:47 [Note] Recovering after a crash using trxfw-bin 050825 7:01:47 [Note] Starting crash recovery... 050825 7:01:47 [Note] Crash recovery finished. 050825 7:01:47 [Note] /usr/local/mysql/libexec/mysqld: ready for connections. Version: '5.0.11-beta-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution 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=268435456 read_buffer_size=1044480 max_used_connections=28 max_connections=800 threads_connected=14 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1897337 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8ade498 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=0x5260ec48, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8146f4c 0x400517ce 0x42074d8e 0x42075bcc 0x81887e6 0x8185cd8 0x8219980 0x8186548 0x818233a 0x815a1a5 0x816095e 0x8158a10 0x815856d 0x8157ace 0x4004c881 0x420e40c7 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 0x8af7d30 = SELECT `Bay Schedule Table`.`IN_NUM` ,`Bay Schedule Table`.`BAY` ,`Bay Schedule Table`.`POSITION` ,`Bay Schedule Table`.`IN_DATE` ,`Bay Schedule Table`.`OUT_DATE` ,`Bay Schedule Table`.`DELAY_DAYS` ,`Derunit`.`DERRICK_DUE_DATE` ,`Bay Schedule Table`.`DK_NUM` ,`Derunit`.`MODEL` ,`Derunit`.`LINE` ,SUM(`Bay Schedule Table`.`HOURS_WORKED` ) ,COUNT(`Bay Schedule Table`.`HOURS_WORKED` ) FROM `Derunit`,`Bay Schedule Table` WHERE (((`Bay Schedule Table`.`DK_NUM` = `Derunit`.`UNIT` ) AND (`Bay Schedule Table`.`IN_NUM` = `Derunit`.`INSTALLATION_ORDER_NUMBER` ) ) AND ((`Bay Schedule Table`.`IN_UNIT_MTH` = 'AUGUST' ) AND (`Bay Schedule Table`.`IN_UNIT_YEAR` = 2005 ) ) ) GROUP BY `Bay Schedule Table`.`IN_NUM` ,`Bay Schedule Table`.`BAY` ,`Bay Schedule Table`.`POSITION` ,`Bay Schedule Table`.`IN_DATE` ,`Bay Schedule Table`.`OUT_DATE` ,`Bay Schedule Table`.`DELAY_DAYS` ,`Derunit`.`DERRICK_DUE_DATE` ,`Bay Schedule Table`.`DK_NUM` ,`Derunit`.`MODEL` ,`Derunit`.`LINE` ORDER BY `Bay Schedule Table`.`BAY` ,`Bay Schedule Tab thd->thread_id=6465 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: 1 mysqld process hanging, pid 24530 - killed 050825 08:24:36 mysqld restarted 050825 8:24:36 [ERROR] Can't start server: Bind on TCP/IP port: Address already in use 050825 8:24:36 [ERROR] Do you already have another mysqld server running on port: 3306 ? 050825 8:24:36 [ERROR] Aborting 050825 8:24:36 [Note] /usr/local/mysql/libexec/mysqld: Shutdown complete 050825 08:24:36 mysqld ended