070405 18:19:35 mysqld started 070405 18:19:35 [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=adflow-bin' to avoid this problem. /usr/local/mysql/bin/mysqld: File './adflow-bin.index' not found (Errcode: 13) 070405 18:19:35 [ERROR] Aborting 070405 18:19:35 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete 070405 18:19:35 mysqld ended 070405 18:19:44 mysqld started 070405 18:19:44 [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=adflow-bin' to avoid this problem. /usr/local/mysql/bin/mysqld: File './adflow-bin.index' not found (Errcode: 13) 070405 18:19:44 [ERROR] Aborting 070405 18:19:44 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete 070405 18:19:44 mysqld ended 070405 18:21:15 mysqld started 070405 18:21:15 [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=adflow-bin' to avoid this problem. /usr/local/mysql/bin/mysqld: File './adflow-bin.index' not found (Errcode: 13) 070405 18:21:15 [ERROR] Aborting 070405 18:21:15 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete 070405 18:21:15 mysqld ended 070405 18:25:05 mysqld started 070405 18:25: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=adflow-bin' to avoid this problem. InnoDB: The first specified data file ./ibdata1 did not exist: InnoDB: a new database to be created! 070405 18:25:05 InnoDB: Setting file ./ibdata1 size to 10 MB InnoDB: Database physically writes the file full: wait... 070405 18:25:05 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... 070405 18:25:05 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 070405 18:25:06 InnoDB: Started; log sequence number 0 0 070405 18:25:06 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 155272064 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070406 10:12:57InnoDB: Assertion failure in thread 2540121008 in file fil0fil.c line 3959 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. 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=65 max_connections=100 threads_connected=56 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x97c652a8 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=0x976709fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x922de8 0x27493a 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 0x9750a008 is invalid pointer thd->thread_id=458 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 070406 10:12:57 mysqld restarted 070406 10:12:57 [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=adflow-bin' to avoid this problem. 070406 10:12:57 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... 070406 10:12:57 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 249032248. InnoDB: Doing recovery: scanned up to log sequence number 0 249032248 InnoDB: Last MySQL binlog file position 0 199658420, file name ./adflow-bin.000003 070406 10:12:57 InnoDB: Started; log sequence number 0 249032248 070406 10:12:57 [Note] Recovering after a crash using adflow-bin 070406 10:13:06 [Note] Starting crash recovery... 070406 10:13:06 [Note] Crash recovery finished. 070406 10:13:06 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 109986688 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070406 13:39:23InnoDB: Assertion failure in thread 2537352112 in file fil0fil.c line 3959 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. 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=50 max_connections=100 threads_connected=49 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x99c2b30 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=0x973cc9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xb66de8 0x3fb93a 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 0x99d0058 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070406 13:39:23 mysqld restarted 070406 13:39:23 [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=adflow-bin' to avoid this problem. 070406 13:39:23 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... 070406 13:39:23 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 249125457. InnoDB: Doing recovery: scanned up to log sequence number 0 249125457 InnoDB: Last MySQL binlog file position 0 95375, file name ./adflow-bin.000004 070406 13:39:23 InnoDB: Started; log sequence number 0 249125457 070406 13:39:23 [Note] Recovering after a crash using adflow-bin 070406 13:39:23 [Note] Starting crash recovery... 070406 13:39:23 [Note] Crash recovery finished. 070406 13:39:23 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 92488064 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070412 12:41:59InnoDB: Assertion failure in thread 2526088112 in file fil0fil.c line 3959 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. 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=74 max_connections=100 threads_connected=59 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x974e3dc8 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=0x9690e9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 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 0x94f31a10 is invalid pointer thd->thread_id=2153 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 070412 12:41:59 mysqld restarted 070412 12:41:59 [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=adflow-bin' to avoid this problem. 070412 12:41:59 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... 070412 12:41:59 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 254711153. InnoDB: Doing recovery: scanned up to log sequence number 0 254711153 InnoDB: Last MySQL binlog file position 0 4750252, file name ./adflow-bin.000005 070412 12:42:00 InnoDB: Started; log sequence number 0 254711153 070412 12:42:00 [Note] Recovering after a crash using adflow-bin 070412 12:42:00 [Note] Starting crash recovery... 070412 12:42:00 [Note] Crash recovery finished. 070412 12:42:00 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 165560704 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070417 8:53:47InnoDB: Assertion failure in thread 2520714160 in file fil0fil.c line 3959 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. 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=65 max_connections=100 threads_connected=37 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x96eb490 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=0x963ee9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 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 0x9572920 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=3432 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 070417 08:53:47 mysqld restarted 070417 8:53:47 [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=adflow-bin' to avoid this problem. 070417 8:53:47 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... 070417 8:53:47 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 258359915. InnoDB: Doing recovery: scanned up to log sequence number 0 258359915 InnoDB: Last MySQL binlog file position 0 3309475, file name ./adflow-bin.000006 070417 8:53:48 InnoDB: Started; log sequence number 0 258359915 070417 8:53:48 [Note] Recovering after a crash using adflow-bin 070417 8:53:48 [Note] Starting crash recovery... 070417 8:53:48 [Note] Crash recovery finished. 070417 8:53:48 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 96551296 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070417 10:17:41InnoDB: Assertion failure in thread 2539711408 in file fil0fil.c line 3959 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. 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=34 max_connections=100 threads_connected=33 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8b32940 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=0x9760c9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xc4fde8 0x90a93a 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 0x8b5ae28 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070417 10:17:41 mysqld restarted 070417 10:17:41 [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=adflow-bin' to avoid this problem. 070417 10:17:41 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... 070417 10:17:41 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 258370132. InnoDB: Doing recovery: scanned up to log sequence number 0 258370132 InnoDB: Last MySQL binlog file position 0 14466, file name ./adflow-bin.000007 070417 10:17:41 InnoDB: Started; log sequence number 0 258370132 070417 10:17:41 [Note] Recovering after a crash using adflow-bin 070417 10:17:41 [Note] Starting crash recovery... 070417 10:17:41 [Note] Crash recovery finished. 070417 10:17:42 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 96551296 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070417 10:17:49InnoDB: Assertion failure in thread 2539731888 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x97e7638 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=0x976119dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x22fde8 0xfa193a 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 0x980fe68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070417 10:17:50 mysqld restarted 070417 10:17:50 [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=adflow-bin' to avoid this problem. 070417 10:17:50 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... 070417 10:17:50 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 258370171. InnoDB: Doing recovery: scanned up to log sequence number 0 258370181 InnoDB: Last MySQL binlog file position 0 14466, file name ./adflow-bin.000007 070417 10:17:50 InnoDB: Started; log sequence number 0 258370181 070417 10:17:50 [Note] Recovering after a crash using adflow-bin 070417 10:17:50 [Note] Starting crash recovery... 070417 10:17:50 [Note] Crash recovery finished. 070417 10:17:50 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 96551296 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070417 10:18:04InnoDB: Assertion failure in thread 2539527088 in file fil0fil.c line 3959 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. 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=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa3babf0 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=0x975df9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 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 0xa3fd0c8 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070417 10:18:04 mysqld restarted 070417 10:18:04 [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=adflow-bin' to avoid this problem. 070417 10:18:04 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... 070417 10:18:04 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 258370191. InnoDB: Doing recovery: scanned up to log sequence number 0 258370191 InnoDB: Last MySQL binlog file position 0 14466, file name ./adflow-bin.000007 070417 10:18:04 InnoDB: Started; log sequence number 0 258370191 070417 10:18:04 [Note] Recovering after a crash using adflow-bin 070417 10:18:04 [Note] Starting crash recovery... 070417 10:18:04 [Note] Crash recovery finished. 070417 10:18:05 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 96551296 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070417 10:19:19InnoDB: Assertion failure in thread 2539719600 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8ed6638 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=0x9760e9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 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 0x8efee68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070417 10:19:19 mysqld restarted 070417 10:19:19 [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=adflow-bin' to avoid this problem. 070417 10:19:19 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... 070417 10:19:20 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 258370201. InnoDB: Doing recovery: scanned up to log sequence number 0 258370201 InnoDB: Last MySQL binlog file position 0 14466, file name ./adflow-bin.000007 070417 10:19:20 InnoDB: Started; log sequence number 0 258370201 070417 10:19:20 [Note] Recovering after a crash using adflow-bin 070417 10:19:20 [Note] Starting crash recovery... 070417 10:19:20 [Note] Crash recovery finished. 070417 10:19:20 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 69484928 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070417 10:21:41InnoDB: Assertion failure in thread 2539506608 in file fil0fil.c line 3959 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. 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=3 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8cbcbf0 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=0x975da9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x1e3de8 0xe7793a 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 0x8cffba0 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070417 10:21:41 mysqld restarted 070417 10:21:41 [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=adflow-bin' to avoid this problem. 070417 10:21:41 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... 070417 10:21:41 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 258372518. InnoDB: Doing recovery: scanned up to log sequence number 0 258372518 InnoDB: Last MySQL binlog file position 0 3627, file name ./adflow-bin.000011 070417 10:21:41 InnoDB: Started; log sequence number 0 258372518 070417 10:21:41 [Note] Recovering after a crash using adflow-bin 070417 10:21:41 [Note] Starting crash recovery... 070417 10:21:41 [Note] Crash recovery finished. 070417 10:21:41 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 69484928 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070417 10:21:49InnoDB: Assertion failure in thread 2539727792 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa462638 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=0x976109dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x278de8 0x71793a 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 0xa48ae68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070417 10:21:50 mysqld restarted 070417 10:21:50 [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=adflow-bin' to avoid this problem. 070417 10:21:50 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... 070417 10:21:50 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 258372518. InnoDB: Doing recovery: scanned up to log sequence number 0 258372528 InnoDB: Last MySQL binlog file position 0 3627, file name ./adflow-bin.000011 070417 10:21:50 InnoDB: Started; log sequence number 0 258372528 070417 10:21:50 [Note] Recovering after a crash using adflow-bin 070417 10:21:50 [Note] Starting crash recovery... 070417 10:21:50 [Note] Crash recovery finished. 070417 10:21:50 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 69484928 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070417 10:29:58InnoDB: Assertion failure in thread 2539477936 in file fil0fil.c line 3959 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. 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=4 max_connections=100 threads_connected=3 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x97473e0 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=0x975d39dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x186de8 0x26e93a 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 0x97525c0 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070417 10:29:58 mysqld restarted 070417 10:29:58 [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=adflow-bin' to avoid this problem. 070417 10:29:58 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... 070417 10:29:58 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 258383606. InnoDB: Doing recovery: scanned up to log sequence number 0 258383606 InnoDB: Last MySQL binlog file position 0 20224, file name ./adflow-bin.000013 070417 10:29:58 InnoDB: Started; log sequence number 0 258383606 070417 10:29:58 [Note] Recovering after a crash using adflow-bin 070417 10:29:58 [Note] Starting crash recovery... 070417 10:29:58 [Note] Crash recovery finished. 070417 10:29:58 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 106578304 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070417 10:33:27InnoDB: Assertion failure in thread 2539506608 in file fil0fil.c line 3959 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. 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=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa0fb188 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=0x975da9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x73cde8 0x90793a 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 0xa127800 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070417 10:33:27 mysqld restarted 070417 10:33:27 [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=adflow-bin' to avoid this problem. 070417 10:33:27 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... 070417 10:33:27 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 258383616. InnoDB: Doing recovery: scanned up to log sequence number 0 258383616 InnoDB: Last MySQL binlog file position 0 20224, file name ./adflow-bin.000013 070417 10:33:27 InnoDB: Started; log sequence number 0 258383616 070417 10:33:27 [Note] Recovering after a crash using adflow-bin 070417 10:33:27 [Note] Starting crash recovery... 070417 10:33:27 [Note] Crash recovery finished. 070417 10:33:28 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 162873728 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070423 17:57:59InnoDB: Assertion failure in thread 2539723696 in file fil0fil.c line 3959 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. 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=68 max_connections=100 threads_connected=55 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x96834980 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=0x9760f9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 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 0xa5f1f68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=4687 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 070423 17:57:59 mysqld restarted 070423 17:57:59 [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=adflow-bin' to avoid this problem. 070423 17:57:59 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... 070423 17:58:00 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 262883417. InnoDB: Doing recovery: scanned up to log sequence number 0 262883417 InnoDB: Last MySQL binlog file position 0 4148433, file name ./adflow-bin.000015 070423 17:58:00 InnoDB: Started; log sequence number 0 262883417 070423 17:58:00 [Note] Recovering after a crash using adflow-bin 070423 17:58:00 [Note] Starting crash recovery... 070423 17:58:00 [Note] Crash recovery finished. 070423 17:58:00 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 162873728 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070423 17:58:06InnoDB: Assertion failure in thread 2539670448 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa821940 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=0x976029fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xae0de8 0x20293a 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 0xa849e28 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070423 17:58:06 mysqld restarted 070423 17:58:06 [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=adflow-bin' to avoid this problem. 070423 17:58:06 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... 070423 17:58:06 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 262883427. InnoDB: Doing recovery: scanned up to log sequence number 0 262883427 InnoDB: Last MySQL binlog file position 0 4148433, file name ./adflow-bin.000015 070423 17:58:06 InnoDB: Started; log sequence number 0 262883427 070423 17:58:06 [Note] Recovering after a crash using adflow-bin 070423 17:58:06 [Note] Starting crash recovery... 070423 17:58:06 [Note] Crash recovery finished. 070423 17:58:07 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 162873728 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070423 17:58:20InnoDB: Assertion failure in thread 2539703216 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa029638 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=0x9760a9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x76cde8 0x36e93a 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 0xa051e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070423 17:58:20 mysqld restarted 070423 17:58:20 [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=adflow-bin' to avoid this problem. 070423 17:58:20 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... 070423 17:58:20 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 262883437. InnoDB: Doing recovery: scanned up to log sequence number 0 262883437 InnoDB: Last MySQL binlog file position 0 4148433, file name ./adflow-bin.000015 070423 17:58:20 InnoDB: Started; log sequence number 0 262883437 070423 17:58:20 [Note] Recovering after a crash using adflow-bin 070423 17:58:20 [Note] Starting crash recovery... 070423 17:58:20 [Note] Crash recovery finished. 070423 17:58:20 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 162873728 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070423 17:58:34InnoDB: Assertion failure in thread 2539682736 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8b6e638 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=0x976059fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xd46de8 0x35293a 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 0x8b96e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070423 17:58:34 mysqld restarted 070423 17:58:34 [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=adflow-bin' to avoid this problem. 070423 17:58: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... 070423 17:58:34 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 262883437. InnoDB: Doing recovery: scanned up to log sequence number 0 262883447 InnoDB: Last MySQL binlog file position 0 4148433, file name ./adflow-bin.000015 070423 17:58:34 InnoDB: Started; log sequence number 0 262883447 070423 17:58:34 [Note] Recovering after a crash using adflow-bin 070423 17:58:34 [Note] Starting crash recovery... 070423 17:58:34 [Note] Crash recovery finished. 070423 17:58:34 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 54477184 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070423 18:07:55InnoDB: Assertion failure in thread 2538699696 in file fil0fil.c line 3959 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. 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=12 max_connections=100 threads_connected=11 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa82aec0 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=0x975159dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x475de8 0xb0d93a 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 0xa836368 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=12 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 070423 18:07:55 mysqld restarted 070423 18:07:55 [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=adflow-bin' to avoid this problem. 070423 18:07:55 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... 070423 18:07:55 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 262939541. InnoDB: Doing recovery: scanned up to log sequence number 0 262939541 InnoDB: Last MySQL binlog file position 0 55372, file name ./adflow-bin.000019 070423 18:07:55 InnoDB: Started; log sequence number 0 262939541 070423 18:07:55 [Note] Recovering after a crash using adflow-bin 070423 18:07:55 [Note] Starting crash recovery... 070423 18:07:55 [Note] Crash recovery finished. 070423 18:07:55 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 54477184 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070423 18:07:59InnoDB: Assertion failure in thread 2539719600 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9268638 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=0x9760e9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 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 0x9290e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070423 18:07:59 mysqld restarted 070423 18:07:59 [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=adflow-bin' to avoid this problem. 070423 18:07:59 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... 070423 18:07:59 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 262939541. InnoDB: Doing recovery: scanned up to log sequence number 0 262939551 InnoDB: Last MySQL binlog file position 0 55372, file name ./adflow-bin.000019 070423 18:07:59 InnoDB: Started; log sequence number 0 262939551 070423 18:07:59 [Note] Recovering after a crash using adflow-bin 070423 18:07:59 [Note] Starting crash recovery... 070423 18:07:59 [Note] Crash recovery finished. 070423 18:07:59 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 54477184 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070423 18:08:02InnoDB: Assertion failure in thread 2539674544 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9de0638 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=0x976039dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x2bdde8 0x4b593a 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 0x9e08e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070423 18:08:03 mysqld restarted 070423 18:08:03 [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=adflow-bin' to avoid this problem. 070423 18:08: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... 070423 18:08:03 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 262939551. InnoDB: Doing recovery: scanned up to log sequence number 0 262939561 InnoDB: Last MySQL binlog file position 0 55372, file name ./adflow-bin.000019 070423 18:08:03 InnoDB: Started; log sequence number 0 262939561 070423 18:08:03 [Note] Recovering after a crash using adflow-bin 070423 18:08:03 [Note] Starting crash recovery... 070423 18:08:03 [Note] Crash recovery finished. 070423 18:08:03 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 54477184 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070423 18:08:06InnoDB: Assertion failure in thread 2539711408 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x954a638 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=0x9760c9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xcb1de8 0x1ed93a 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 0x9572e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070423 18:08:06 mysqld restarted 070423 18:08:06 [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=adflow-bin' to avoid this problem. 070423 18:08:06 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... 070423 18:08:06 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 262939561. InnoDB: Doing recovery: scanned up to log sequence number 0 262939571 InnoDB: Last MySQL binlog file position 0 55372, file name ./adflow-bin.000019 070423 18:08:06 InnoDB: Started; log sequence number 0 262939571 070423 18:08:06 [Note] Recovering after a crash using adflow-bin 070423 18:08:06 [Note] Starting crash recovery... 070423 18:08:06 [Note] Crash recovery finished. 070423 18:08:06 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 106971520 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070423 18:08:30InnoDB: Assertion failure in thread 2539723696 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x90ea638 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=0x9760f9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 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 0x9112e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070423 18:08:30 mysqld restarted 070423 18:08: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=adflow-bin' to avoid this problem. 070423 18:08: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... 070423 18:08:30 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 262939571. InnoDB: Doing recovery: scanned up to log sequence number 0 262939581 InnoDB: Last MySQL binlog file position 0 55372, file name ./adflow-bin.000019 070423 18:08:30 InnoDB: Started; log sequence number 0 262939581 070423 18:08:30 [Note] Recovering after a crash using adflow-bin 070423 18:08:30 [Note] Starting crash recovery... 070423 18:08:30 [Note] Crash recovery finished. 070423 18:08:31 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 106971520 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070423 18:08:36InnoDB: Assertion failure in thread 2539719600 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8ba8638 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=0x9760e9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 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 0x8bd0e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070423 18:08:36 mysqld restarted 070423 18:08:36 [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=adflow-bin' to avoid this problem. 070423 18:08:36 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... 070423 18:08:36 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 262939581. InnoDB: Doing recovery: scanned up to log sequence number 0 262939591 InnoDB: Last MySQL binlog file position 0 55372, file name ./adflow-bin.000019 070423 18:08:36 InnoDB: Started; log sequence number 0 262939591 070423 18:08:36 [Note] Recovering after a crash using adflow-bin 070423 18:08:36 [Note] Starting crash recovery... 070423 18:08:36 [Note] Crash recovery finished. 070423 18:08:36 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 169033600 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070426 16:38:18InnoDB: Assertion failure in thread 2534095792 in file fil0fil.c line 3959 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. 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=76 max_connections=100 threads_connected=61 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa286ce0 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=0x970b19dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x771de8 0x91193a 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 0xa10c960 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=2661 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 070426 16:38:18 mysqld restarted 070426 16:38:18 [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=adflow-bin' to avoid this problem. 070426 16:38:18 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... 070426 16:38:18 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 267933030. InnoDB: Doing recovery: scanned up to log sequence number 0 267933030 InnoDB: Last MySQL binlog file position 0 4919690, file name ./adflow-bin.000025 070426 16:38:19 InnoDB: Started; log sequence number 0 267933030 070426 16:38:19 [Note] Recovering after a crash using adflow-bin 070426 16:38:19 [Note] Starting crash recovery... 070426 16:38:19 [Note] Crash recovery finished. 070426 16:38:19 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 31080320 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070430 15:15:21InnoDB: Assertion failure in thread 2530483120 in file fil0fil.c line 3959 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. 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=59 max_connections=100 threads_connected=35 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x973a7000 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=0x96d3f9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 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 0x9adc038 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=2710 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 070430 15:15:21 mysqld restarted 070430 15:15:21 [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=adflow-bin' to avoid this problem. 070430 15:15: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... 070430 15:15:21 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 272930318. InnoDB: Doing recovery: scanned up to log sequence number 0 272930666 070430 15:15:21 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 4784572, file name ./adflow-bin.000026 070430 15:15:22 InnoDB: Started; log sequence number 0 272930666 070430 15:15:22 [Note] Recovering after a crash using adflow-bin 070430 15:15:22 [Note] Starting crash recovery... 070430 15:15:22 [Note] Crash recovery finished. 070430 15:15:22 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 31080320 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070430 15:15:33InnoDB: Assertion failure in thread 2539715504 in file fil0fil.c line 3959 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. 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=4 max_connections=100 threads_connected=4 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x987f638 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=0x9760d9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xdc4de8 0x26193a 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... InnoDB: Thread 3010292656 stopped in file os0sync.c line 501 thd->query at 0x98a7e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070430 15:15:33 mysqld restarted 070430 15:15:33 [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=adflow-bin' to avoid this problem. 070430 15:15:33 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... 070430 15:15:33 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 272930666. InnoDB: Doing recovery: scanned up to log sequence number 0 272930676 InnoDB: Last MySQL binlog file position 0 4784572, file name ./adflow-bin.000026 070430 15:15:33 InnoDB: Started; log sequence number 0 272930676 070430 15:15:33 [Note] Recovering after a crash using adflow-bin 070430 15:15:33 [Note] Starting crash recovery... 070430 15:15:33 [Note] Crash recovery finished. 070430 15:15:34 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 31080320 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070430 15:15:47InnoDB: Assertion failure in thread 2539125680 in file fil0fil.c line 3959 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. 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=4 max_connections=100 threads_connected=4 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa218e98 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=0x9757d9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x7c2de8 0x21a93a 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... InnoDB: Thread 3010304944 stopped in file os0sync.c line 501 thd->query at 0xa225af8 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=4 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 070430 15:15:47 mysqld restarted 070430 15:15:47 [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=adflow-bin' to avoid this problem. 070430 15:15:47 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... 070430 15:15:47 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 272930676. InnoDB: Doing recovery: scanned up to log sequence number 0 272930686 InnoDB: Last MySQL binlog file position 0 4784572, file name ./adflow-bin.000026 070430 15:15:47 InnoDB: Started; log sequence number 0 272930686 070430 15:15:47 [Note] Recovering after a crash using adflow-bin 070430 15:15:47 [Note] Starting crash recovery... 070430 15:15:47 [Note] Crash recovery finished. 070430 15:15:47 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 31080320 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070430 15:15:56InnoDB: Assertion failure in thread 2538277808 in file fil0fil.c line 3959 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. 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=4 max_connections=100 InnoDB: Thread 3010304944 stopped in file os0sync.c line 501 threads_connected=4 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x93fb528 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=0x974ae9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 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 0x9407098 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070430 15:15:56 mysqld restarted 070430 15:15:56 [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=adflow-bin' to avoid this problem. 070430 15:15:56 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... 070430 15:15:56 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 272930686. InnoDB: Doing recovery: scanned up to log sequence number 0 272931088 070430 15:15:56 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 391, file name ./adflow-bin.000029 070430 15:15:57 InnoDB: Started; log sequence number 0 272931088 070430 15:15:57 [Note] Recovering after a crash using adflow-bin 070430 15:15:57 [Note] Starting crash recovery... 070430 15:15:57 [Note] Crash recovery finished. 070430 15:15:57 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 31080320 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070430 15:19:43InnoDB: Assertion failure in thread 2538916784 in file fil0fil.c line 3959 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. 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=17 max_connections=100 threads_connected=16 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa3b4808 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=0x9754a9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x428de8 0x27093a 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 0xa3b7c90 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=5 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 070430 15:19:43 mysqld restarted 070430 15:19:43 [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=adflow-bin' to avoid this problem. 070430 15:19:43 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... 070430 15:19:43 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 272962472. InnoDB: Doing recovery: scanned up to log sequence number 0 272962864 070430 15:19:43 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 17741, file name ./adflow-bin.000030 070430 15:19:44 InnoDB: Started; log sequence number 0 272962864 070430 15:19:44 [Note] Recovering after a crash using adflow-bin 070430 15:19:44 [Note] Starting crash recovery... 070430 15:19:44 [Note] Crash recovery finished. 070430 15:19:44 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 31080320 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070430 15:19:55InnoDB: Assertion failure in thread 2539723696 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa1e0638 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=0x9760f9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 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 0xa208e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070430 15:19:56 mysqld restarted 070430 15:19:56 [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=adflow-bin' to avoid this problem. 070430 15:19:56 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... 070430 15:19:56 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 272962903. InnoDB: Doing recovery: scanned up to log sequence number 0 272962913 InnoDB: Last MySQL binlog file position 0 17741, file name ./adflow-bin.000030 070430 15:19:56 InnoDB: Started; log sequence number 0 272962913 070430 15:19:56 [Note] Recovering after a crash using adflow-bin 070430 15:19:56 [Note] Starting crash recovery... 070430 15:19:56 [Note] Crash recovery finished. 070430 15:19:56 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 171917184 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070430 15:20:21InnoDB: Assertion failure in thread 2539723696 in file fil0fil.c line 3959 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. 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=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9ec4638 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=0x9760f9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 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 0x9eece68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070430 15:20:21 mysqld restarted 070430 15:20:21 [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=adflow-bin' to avoid this problem. 070430 15:20: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... 070430 15:20:22 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 272990618. InnoDB: Doing recovery: scanned up to log sequence number 0 272990618 InnoDB: Last MySQL binlog file position 0 15556, file name ./adflow-bin.000032 070430 15:20:22 InnoDB: Started; log sequence number 0 272990618 070430 15:20:22 [Note] Recovering after a crash using adflow-bin 070430 15:20:22 [Note] Starting crash recovery... 070430 15:20:22 [Note] Crash recovery finished. 070430 15:20:22 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 92487040 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:25:47InnoDB: Assertion failure in thread 2532522928 in file fil0fil.c line 3959 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. 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=61 max_connections=100 threads_connected=47 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x974e48b0 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=0x96f319dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x841de8 0xbe893a 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 0x9a35c98 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=2699 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 070503 15:25:47 mysqld restarted 070503 15:25:47 [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=adflow-bin' to avoid this problem. 070503 15:25:47 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... 070503 15:25:47 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 278236336. InnoDB: Doing recovery: scanned up to log sequence number 0 278236336 InnoDB: Last MySQL binlog file position 0 5151726, file name ./adflow-bin.000033 070503 15:25:47 InnoDB: Started; log sequence number 0 278236336 070503 15:25:47 [Note] Recovering after a crash using adflow-bin 070503 15:25:48 [Note] Starting crash recovery... 070503 15:25:48 [Note] Crash recovery finished. 070503 15:25:48 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 11943296 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:25:52InnoDB: Assertion failure in thread 2539731888 in file fil0fil.c line 3959 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. 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=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa3c4940 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=0x976119dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d InnoDB: Thread 3010309040 stopped in file os0sync.c line 501 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x5bcde8 0x99a93a 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 0xa3ece28 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:25:52 mysqld restarted 070503 15:25:52 [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=adflow-bin' to avoid this problem. 070503 15:25:52 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... 070503 15:25:52 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 278236336. InnoDB: Doing recovery: scanned up to log sequence number 0 278236346 InnoDB: Last MySQL binlog file position 0 5151726, file name ./adflow-bin.000033 070503 15:25:52 InnoDB: Started; log sequence number 0 278236346 070503 15:25:52 [Note] Recovering after a crash using adflow-bin 070503 15:25:52 [Note] Starting crash recovery... 070503 15:25:52 [Note] Crash recovery finished. 070503 15:25:52 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 30948736 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:26:12InnoDB: Assertion failure in thread 2538478512 in file fil0fil.c line 3959 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. 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=4 max_connections=100 threads_connected=3 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x934fe58 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=0x974df9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 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 0x9417268 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070503 15:26:12 mysqld restarted 070503 15:26:12 [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=adflow-bin' to avoid this problem. 070503 15:26:13 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... 070503 15:26:13 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 278236356. InnoDB: Doing recovery: scanned up to log sequence number 0 278236839 070503 15:26:13 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 271, file name ./adflow-bin.000035 070503 15:26:13 InnoDB: Started; log sequence number 0 278236839 070503 15:26:13 [Note] Recovering after a crash using adflow-bin 070503 15:26:13 [Note] Starting crash recovery... 070503 15:26:13 [Note] Crash recovery finished. 070503 15:26:13 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 172506496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:26:22InnoDB: Assertion failure in thread 2539723696 in file fil0fil.c line 3959 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. 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=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa03a638 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=0x9760f9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 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 0xa062e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:26:22 mysqld restarted 070503 15:26:22 [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=adflow-bin' to avoid this problem. 070503 15:26:22 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... 070503 15:26:22 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 278236849. InnoDB: Doing recovery: scanned up to log sequence number 0 278236849 InnoDB: Last MySQL binlog file position 0 271, file name ./adflow-bin.000035 070503 15:26:22 InnoDB: Started; log sequence number 0 278236849 070503 15:26:22 [Note] Recovering after a crash using adflow-bin 070503 15:26:22 [Note] Starting crash recovery... 070503 15:26:22 [Note] Crash recovery finished. 070503 15:26:22 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 172506496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:26:45InnoDB: Assertion failure in thread 2539699120 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa34a638 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=0x976099dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x289de8 0xa3d93a 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 0xa372e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:26:45 mysqld restarted 070503 15:26:45 [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=adflow-bin' to avoid this problem. 070503 15:26:45 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... 070503 15:26:45 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 278237579. InnoDB: Doing recovery: scanned up to log sequence number 0 278237579 InnoDB: Last MySQL binlog file position 0 645, file name ./adflow-bin.000037 070503 15:26:45 InnoDB: Started; log sequence number 0 278237579 070503 15:26:45 [Note] Recovering after a crash using adflow-bin 070503 15:26:45 [Note] Starting crash recovery... 070503 15:26:45 [Note] Crash recovery finished. 070503 15:26:45 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 172506496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:26:53InnoDB: Assertion failure in thread 2539703216 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. InnoDB: Thread 3010280368 stopped in file os0sync.c line 501 thd=0x97cf638 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=0x9760a9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xa88de8 0x1ed93a 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 0x97f7e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:26:53 mysqld restarted 070503 15:26:53 [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=adflow-bin' to avoid this problem. 070503 15:26: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... 070503 15:26:53 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 278237579. InnoDB: Doing recovery: scanned up to log sequence number 0 278237589 InnoDB: Last MySQL binlog file position 0 645, file name ./adflow-bin.000037 070503 15:26:53 InnoDB: Started; log sequence number 0 278237589 070503 15:26:53 [Note] Recovering after a crash using adflow-bin 070503 15:26:53 [Note] Starting crash recovery... 070503 15:26:53 [Note] Crash recovery finished. 070503 15:26:54 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 172506496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:27:14InnoDB: Assertion failure in thread 2539719600 in file fil0fil.c line 3959 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. 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=3 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x99e9638 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=0x9760e9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 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... InnoDB: Thread 3010296752 stopped in file os0sync.c line 501 thd->query at 0x9a11e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:27:14 mysqld restarted 070503 15:27:14 [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=adflow-bin' to avoid this problem. 070503 15:27:14 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... 070503 15:27:14 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 278237599. InnoDB: Doing recovery: scanned up to log sequence number 0 278237599 InnoDB: Last MySQL binlog file position 0 645, file name ./adflow-bin.000037 070503 15:27:14 InnoDB: Started; log sequence number 0 278237599 070503 15:27:14 [Note] Recovering after a crash using adflow-bin 070503 15:27:14 [Note] Starting crash recovery... 070503 15:27:14 [Note] Crash recovery finished. 070503 15:27:14 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 172506496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:27:39InnoDB: Assertion failure in thread 2539703216 in file fil0fil.c line 3959 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. 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=3 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa39d638 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=0x9760a9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xdf1de8 0x99a93a 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 0xa3c5e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:27:39 mysqld restarted 070503 15:27:39 [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=adflow-bin' to avoid this problem. 070503 15:27: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... 070503 15:27:40 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 278237609. InnoDB: Doing recovery: scanned up to log sequence number 0 278237609 InnoDB: Last MySQL binlog file position 0 645, file name ./adflow-bin.000037 070503 15:27:40 InnoDB: Started; log sequence number 0 278237609 070503 15:27:40 [Note] Recovering after a crash using adflow-bin 070503 15:27:40 [Note] Starting crash recovery... 070503 15:27:40 [Note] Crash recovery finished. 070503 15:27:40 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9ca8638 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=0x9760c0bc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x82b5346 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x456de8 0x8c193a 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 0x9cd0e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:27:45 mysqld restarted 070503 15:27:45 [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=adflow-bin' to avoid this problem. 070503 15:27:45 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... 070503 15:27:45 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 278237609. InnoDB: Doing recovery: scanned up to log sequence number 0 278237609 InnoDB: Last MySQL binlog file position 0 645, file name ./adflow-bin.000037 070503 15:27:45 InnoDB: Started; log sequence number 0 278237609 070503 15:27:45 [Note] Recovering after a crash using adflow-bin 070503 15:27:45 [Note] Starting crash recovery... 070503 15:27:45 [Note] Crash recovery finished. 070503 15:27:45 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 172506496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:28:35InnoDB: Assertion failure in thread 2537552816 in file fil0fil.c line 3959 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. 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=6 max_connections=100 threads_connected=5 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x97404c08 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=0x973fd9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x389de8 0x2c493a 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 0x97410748 is invalid pointer thd->thread_id=10 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 070503 15:28:35 mysqld restarted 070503 15:28:35 [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=adflow-bin' to avoid this problem. 070503 15:28:35 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... 070503 15:28:35 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 278240317. InnoDB: Doing recovery: scanned up to log sequence number 0 278240317 InnoDB: Last MySQL binlog file position 0 1237, file name ./adflow-bin.000042 070503 15:28:35 InnoDB: Started; log sequence number 0 278240317 070503 15:28:35 [Note] Recovering after a crash using adflow-bin 070503 15:28:35 [Note] Starting crash recovery... 070503 15:28:35 [Note] Crash recovery finished. 070503 15:28:35 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 172506496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:29:30InnoDB: Assertion failure in thread 2538470320 in file fil0fil.c line 3959 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. 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=3 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9673e78 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=0x974dd9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d InnoDB: Thread 3010296752 stopped in file os0sync.c line 501 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xd23de8 0x1ed93a 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 0x967f970 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070503 15:29:31 mysqld restarted 070503 15:29:31 [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=adflow-bin' to avoid this problem. 070503 15:29:31 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... 070503 15:29:31 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 278240327. InnoDB: Doing recovery: scanned up to log sequence number 0 278240327 InnoDB: Last MySQL binlog file position 0 1237, file name ./adflow-bin.000042 070503 15:29:31 InnoDB: Started; log sequence number 0 278240327 070503 15:29:31 [Note] Recovering after a crash using adflow-bin 070503 15:29:31 [Note] Starting crash recovery... 070503 15:29:31 [Note] Crash recovery finished. 070503 15:29:31 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 172506496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:29:40InnoDB: Assertion failure in thread 2539727792 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa2af638 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=0x976109dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x85ede8 0xdde93a 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 0xa2d7e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:29:40 mysqld restarted 070503 15:29:40 [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=adflow-bin' to avoid this problem. 070503 15:29:40 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... 070503 15:29:40 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 278240337. InnoDB: Doing recovery: scanned up to log sequence number 0 278240337 InnoDB: Last MySQL binlog file position 0 1237, file name ./adflow-bin.000042 070503 15:29:40 InnoDB: Started; log sequence number 0 278240337 070503 15:29:40 [Note] Recovering after a crash using adflow-bin 070503 15:29:40 [Note] Starting crash recovery... 070503 15:29:40 [Note] Crash recovery finished. 070503 15:29:40 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 172506496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:45:26InnoDB: Assertion failure in thread 2539711408 in file fil0fil.c line 3959 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. 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=3 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa3ed638 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=0x9760c9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x7a7de8 0x34c93a 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 0xa416280 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070503 15:45:26 mysqld restarted 070503 15:45:26 [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=adflow-bin' to avoid this problem. 070503 15:45:26 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... 070503 15:45:26 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 278764722. InnoDB: Doing recovery: scanned up to log sequence number 0 278825639 InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 14 row operations to undo InnoDB: Trx id counter is 0 568576 070503 15:45:26 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 572289, file name ./adflow-bin.000045 InnoDB: Starting in background the rollback of uncommitted transactions 070503 15:45:27 InnoDB: Rolling back trx with id 0 568030, 14 rows to undo 070503 15:45:27 InnoDB: Started; log sequence number 0 278825639 070503 15:45:27 [Note] Recovering after a crash using adflow-bin 070503 15:45:27 [Note] Starting crash recovery... 070503 15:45:27 [Note] Crash recovery finished. InnoDB: Rolling back of trx id 0 568030 completed 070503 15:45:27 InnoDB: Rollback of non-prepared transactions completed 070503 15:45:27 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 172506496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:45:33InnoDB: Assertion failure in thread 2537552816 in file fil0fil.c line 3959 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. InnoDB: Thread 2539719600 stopped in file row0mysql.c line 142 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=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9223910 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=0x973fd9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x270de8 0x35893a 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... InnoDB: Thread 3010296752 stopped in file ut0mem.c line 230 thd->query at 0x9239290 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070503 15:45:33 mysqld restarted 070503 15:45:33 [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=adflow-bin' to avoid this problem. 070503 15:45:33 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... 070503 15:45:33 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 278764722. InnoDB: Doing recovery: scanned up to log sequence number 0 278829113 070503 15:45:33 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 572289, file name ./adflow-bin.000045 070503 15:45:34 InnoDB: Started; log sequence number 0 278829113 070503 15:45:34 [Note] Recovering after a crash using adflow-bin 070503 15:45:34 [Note] Starting crash recovery... 070503 15:45:34 [Note] Crash recovery finished. 070503 15:45:34 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 85474688 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:50:10InnoDB: Assertion failure in thread 2539514800 in file fil0fil.c line 3959 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. 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=6 max_connections=100 threads_connected=5 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa4bf1c0 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=0x975dc9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x115de8 0x82593a 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 0xa4caa80 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070503 15:50:10 mysqld restarted 070503 15:50:11 [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=adflow-bin' to avoid this problem. 070503 15:50:11 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... 070503 15:50:11 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 279032434. InnoDB: Doing recovery: scanned up to log sequence number 0 279032434 InnoDB: Last MySQL binlog file position 0 206242, file name ./adflow-bin.000047 070503 15:50:11 InnoDB: Started; log sequence number 0 279032434 070503 15:50:11 [Note] Recovering after a crash using adflow-bin 070503 15:50:11 [Note] Starting crash recovery... 070503 15:50:11 [Note] Crash recovery finished. 070503 15:50:11 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 85474688 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:50:14InnoDB: Assertion failure in thread 2539731888 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8bcf638 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=0x976119dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: InnoDB: Thread 3010309040 stopped in file os0sync.c line 501 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xf0ade8 0x20293a 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 0x8bf7e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:50:14 mysqld restarted 070503 15:50:14 [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=adflow-bin' to avoid this problem. 070503 15:50:14 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... 070503 15:50:14 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 279032434. InnoDB: Doing recovery: scanned up to log sequence number 0 279032444 InnoDB: Last MySQL binlog file position 0 206242, file name ./adflow-bin.000047 070503 15:50:14 InnoDB: Started; log sequence number 0 279032444 070503 15:50:14 [Note] Recovering after a crash using adflow-bin 070503 15:50:14 [Note] Starting crash recovery... 070503 15:50:14 [Note] Crash recovery finished. 070503 15:50:15 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 85474688 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:50:18InnoDB: Assertion failure in thread 2539723696 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x938c638 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=0x9760f9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 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 0x93b4e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:50:18 mysqld restarted 070503 15:50:18 [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=adflow-bin' to avoid this problem. 070503 15:50:18 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... 070503 15:50:18 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 279032444. InnoDB: Doing recovery: scanned up to log sequence number 0 279032454 InnoDB: Last MySQL binlog file position 0 206242, file name ./adflow-bin.000047 070503 15:50:18 InnoDB: Started; log sequence number 0 279032454 070503 15:50:18 [Note] Recovering after a crash using adflow-bin 070503 15:50:18 [Note] Starting crash recovery... 070503 15:50:18 [Note] Crash recovery finished. 070503 15:50:18 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 172506496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:50:34InnoDB: Assertion failure in thread 2539715504 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8c89638 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=0x9760d9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x991de8 0x1ed93a 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 0x8cb1e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:50:34 mysqld restarted 070503 15:50:35 [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=adflow-bin' to avoid this problem. 070503 15:50:35 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... 070503 15:50:35 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 279032464. InnoDB: Doing recovery: scanned up to log sequence number 0 279032464 InnoDB: Last MySQL binlog file position 0 206242, file name ./adflow-bin.000047 070503 15:50:35 InnoDB: Started; log sequence number 0 279032464 070503 15:50:35 [Note] Recovering after a crash using adflow-bin 070503 15:50:35 [Note] Starting crash recovery... 070503 15:50:35 [Note] Crash recovery finished. 070503 15:50:35 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 66010496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:51:14InnoDB: Assertion failure in thread 2539678640 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8bec638 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=0x976049dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x7d5de8 0x1ed93a 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 0x8c14e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:51:14 mysqld restarted 070503 15:51:14 [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=adflow-bin' to avoid this problem. 070503 15:51:14 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... 070503 15:51:15 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 279032474. InnoDB: Doing recovery: scanned up to log sequence number 0 279032474 InnoDB: Last MySQL binlog file position 0 206242, file name ./adflow-bin.000047 070503 15:51:15 InnoDB: Started; log sequence number 0 279032474 070503 15:51:15 [Note] Recovering after a crash using adflow-bin 070503 15:51:15 [Note] Starting crash recovery... 070503 15:51:15 [Note] Crash recovery finished. 070503 15:51:15 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 66010496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:51:19InnoDB: Assertion failure in thread 2539727792 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa0ec638 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=0x976109dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xb3fde8 0x1ed93a 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... InnoDB: Thread 3010304944 stopped in file os0sync.c line 501 thd->query at 0xa114e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:51:19 mysqld restarted 070503 15:51:19 [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=adflow-bin' to avoid this problem. 070503 15:51:19 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... 070503 15:51:19 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 279032474. InnoDB: Doing recovery: scanned up to log sequence number 0 279032484 InnoDB: Last MySQL binlog file position 0 206242, file name ./adflow-bin.000047 070503 15:51:19 InnoDB: Started; log sequence number 0 279032484 070503 15:51:19 [Note] Recovering after a crash using adflow-bin 070503 15:51:19 [Note] Starting crash recovery... 070503 15:51:19 [Note] Crash recovery finished. 070503 15:51:19 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 68894080 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:51:32InnoDB: Assertion failure in thread 2539707312 in file fil0fil.c line 3959 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. 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=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9ce1638 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=0x9760b9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xb35de8 0x1ed93a 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 0x9d09e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:51:32 mysqld restarted 070503 15:51:32 [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=adflow-bin' to avoid this problem. 070503 15:51:33 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... 070503 15:51:33 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 279032484. InnoDB: Doing recovery: scanned up to log sequence number 0 279032912 070503 15:51:33 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000053 070503 15:51:33 InnoDB: Started; log sequence number 0 279032912 070503 15:51:33 [Note] Recovering after a crash using adflow-bin 070503 15:51:33 [Note] Starting crash recovery... 070503 15:51:33 [Note] Crash recovery finished. 070503 15:51:33 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 172506496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:53:01InnoDB: Assertion failure in thread 2539707312 in file fil0fil.c line 3959 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. InnoDB: Thread 2539506608 stopped in file row0sel.c line 2213 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=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa2ad638 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=0x9760b9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x962de8 0x20693a 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 0xa2d5e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:53:01 mysqld restarted 070503 15:53:01 [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=adflow-bin' to avoid this problem. 070503 15:53:01 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... 070503 15:53:02 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 279033324. InnoDB: Doing recovery: scanned up to log sequence number 0 279033324 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000054 070503 15:53:02 InnoDB: Started; log sequence number 0 279033324 070503 15:53:02 [Note] Recovering after a crash using adflow-bin 070503 15:53:02 [Note] Starting crash recovery... 070503 15:53:02 [Note] Crash recovery finished. 070503 15:53:02 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 172506496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:53:18InnoDB: Assertion failure in thread 2539735984 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9d76638 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=0x976129fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x48cde8 0x58693a 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... InnoDB: Thread 3010313136 stopped in file os0sync.c line 501 thd->query at 0x9d9ee68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:53:19 mysqld restarted 070503 15:53:19 [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=adflow-bin' to avoid this problem. 070503 15:53:19 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... 070503 15:53:19 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 279033334. InnoDB: Doing recovery: scanned up to log sequence number 0 279033334 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000054 070503 15:53:19 InnoDB: Started; log sequence number 0 279033334 070503 15:53:19 [Note] Recovering after a crash using adflow-bin 070503 15:53:19 [Note] Starting crash recovery... 070503 15:53:19 [Note] Crash recovery finished. 070503 15:53:19 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 172506496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:53:41InnoDB: Assertion failure in thread 2539715504 in file fil0fil.c line 3959 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. 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=3 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9496638 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=0x9760d9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x723de8 0x1ed93a 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 0x94bee68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:53:41 mysqld restarted 070503 15:53:41 [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=adflow-bin' to avoid this problem. 070503 15:53:41 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... 070503 15:53:41 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 279033360. InnoDB: Doing recovery: scanned up to log sequence number 0 279033360 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000054 070503 15:53:41 InnoDB: Started; log sequence number 0 279033360 070503 15:53:41 [Note] Recovering after a crash using adflow-bin 070503 15:53:41 [Note] Starting crash recovery... 070503 15:53:41 [Note] Crash recovery finished. 070503 15:53:41 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) 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=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa1127a8 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=0x975df0dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x82b5346 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 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 0xa127e98 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070503 15:53:46 mysqld restarted 070503 15:53: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=adflow-bin' to avoid this problem. 070503 15:53: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... 070503 15:53:46 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 279033360. InnoDB: Doing recovery: scanned up to log sequence number 0 279033360 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000054 070503 15:53:46 InnoDB: Started; log sequence number 0 279033360 070503 15:53:46 [Note] Recovering after a crash using adflow-bin 070503 15:53:46 [Note] Starting crash recovery... 070503 15:53:46 [Note] Crash recovery finished. 070503 15:53:46 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 172506496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:54:11InnoDB: Assertion failure in thread 2539707312 in file fil0fil.c line 3959 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. 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=2 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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8ebe638 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=0x9760b9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x7f1de8 0xad993a 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... InnoDB: Thread 3010284464 stopped in file os0sync.c line 501 thd->query at 0x8ee6e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:54:11 mysqld restarted 070503 15:54:11 [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=adflow-bin' to avoid this problem. 070503 15:54:11 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... 070503 15:54:11 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 279034163. InnoDB: Doing recovery: scanned up to log sequence number 0 279034163 InnoDB: Last MySQL binlog file position 0 643, file name ./adflow-bin.000058 070503 15:54:11 InnoDB: Started; log sequence number 0 279034163 070503 15:54:11 [Note] Recovering after a crash using adflow-bin 070503 15:54:11 [Note] Starting crash recovery... 070503 15:54:11 [Note] Crash recovery finished. 070503 15:54:11 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 172506496 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070503 15:55:07InnoDB: Assertion failure in thread 2539678640 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa241638 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=0x976049fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xf50de8 0x1ed93a 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 0xa269e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070503 15:55:07 mysqld restarted 070503 15:55:07 [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=adflow-bin' to avoid this problem. 070503 15:55:07 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... 070503 15:55:07 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 279034173. InnoDB: Doing recovery: scanned up to log sequence number 0 279034173 InnoDB: Last MySQL binlog file position 0 643, file name ./adflow-bin.000058 070503 15:55:07 InnoDB: Started; log sequence number 0 279034173 070503 15:55:07 [Note] Recovering after a crash using adflow-bin 070503 15:55:07 [Note] Starting crash recovery... 070503 15:55:07 [Note] Crash recovery finished. 070503 15:55:08 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 55458688 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070508 15:35:32InnoDB: Assertion failure in thread 2529250224 in file fil0fil.c line 3959 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. 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=58 max_connections=100 threads_connected=51 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xad2bc70 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=0x96c129dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xc7cde8 0x7c393a 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 0xac6f8d8 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=3863 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 070508 15:35:32 mysqld restarted 070508 15:35:32 [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=adflow-bin' to avoid this problem. 070508 15:35:32 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... 070508 15:35:32 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 283440401. InnoDB: Doing recovery: scanned up to log sequence number 0 283441317 070508 15:35:32 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 4233315, file name ./adflow-bin.000060 070508 15:35:33 InnoDB: Started; log sequence number 0 283441317 070508 15:35:33 [Note] Recovering after a crash using adflow-bin 070508 15:35:33 [Note] Starting crash recovery... 070508 15:35:33 [Note] Crash recovery finished. 070508 15:35:33 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 24918912 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070508 15:37:03InnoDB: Assertion failure in thread 2539715504 in file fil0fil.c line 3959 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. 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=3 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa4f8638 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=0x9760d9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xcbade8 0x1ed93a 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 0xa520e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070508 15:37:03 mysqld restarted 070508 15:37:03 [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=adflow-bin' to avoid this problem. 070508 15:37: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... 070508 15:37:03 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 283442761. InnoDB: Doing recovery: scanned up to log sequence number 0 283442761 InnoDB: Last MySQL binlog file position 0 617, file name ./adflow-bin.000061 070508 15:37:04 InnoDB: Started; log sequence number 0 283442761 070508 15:37:04 [Note] Recovering after a crash using adflow-bin 070508 15:37:04 [Note] Starting crash recovery... 070508 15:37:04 [Note] Crash recovery finished. 070508 15:37:04 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 80952192 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070508 16:19:01InnoDB: Assertion failure in thread 2539711408 in file fil0fil.c line 3959 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. 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=5 max_connections=100 threads_connected=3 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa7f4638 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=0x9760c9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xb27de8 0x24493a 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 0xa81ce68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070508 16:19:01 mysqld restarted 070508 16:19:01 [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=adflow-bin' to avoid this problem. 070508 16:19:01 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... 070508 16:19:01 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 283851965. InnoDB: Doing recovery: scanned up to log sequence number 0 283852879 070508 16:19:01 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 359057, file name ./adflow-bin.000062 070508 16:19:02 InnoDB: Started; log sequence number 0 283852879 070508 16:19:02 [Note] Recovering after a crash using adflow-bin 070508 16:19:02 [Note] Starting crash recovery... 070508 16:19:02 [Note] Crash recovery finished. 070508 16:19:02 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 80952192 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070508 16:19:05InnoDB: Assertion failure in thread 2539719600 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9b29638 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=0x9760e9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 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 0x9b51e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070508 16:19:05 mysqld restarted 070508 16:19: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=adflow-bin' to avoid this problem. 070508 16:19:05 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... 070508 16:19:05 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 283852879. InnoDB: Doing recovery: scanned up to log sequence number 0 283852889 InnoDB: Last MySQL binlog file position 0 359057, file name ./adflow-bin.000062 070508 16:19:05 InnoDB: Started; log sequence number 0 283852889 070508 16:19:05 [Note] Recovering after a crash using adflow-bin 070508 16:19:05 [Note] Starting crash recovery... 070508 16:19:05 [Note] Crash recovery finished. 070508 16:19:06 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 80952192 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070508 16:19:08InnoDB: Assertion failure in thread 2539707312 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9972638 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=0x9760b9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x6d2de8 0x9d293a 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 0x999ae68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070508 16:19:09 mysqld restarted 070508 16:19:09 [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=adflow-bin' to avoid this problem. 070508 16:19:09 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... 070508 16:19:09 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 283852889. InnoDB: Doing recovery: scanned up to log sequence number 0 283852899 InnoDB: Last MySQL binlog file position 0 359057, file name ./adflow-bin.000062 070508 16:19:09 InnoDB: Started; log sequence number 0 283852899 070508 16:19:09 [Note] Recovering after a crash using adflow-bin 070508 16:19:09 [Note] Starting crash recovery... 070508 16:19:09 [Note] Crash recovery finished. 070508 16:19:09 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 80952192 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070508 16:25:06InnoDB: Assertion failure in thread 2538425264 in file fil0fil.c line 3959 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. 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=4 max_connections=100 threads_connected=3 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x92c4b60 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=0x974d29dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x314de8 0x80293a 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 0x92d06d0 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070508 16:25:06 mysqld restarted 070508 16:25:06 [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=adflow-bin' to avoid this problem. 070508 16:25:06 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... 070508 16:25:06 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 283882395. InnoDB: Doing recovery: scanned up to log sequence number 0 283882395 InnoDB: Last MySQL binlog file position 0 28523, file name ./adflow-bin.000065 070508 16:25:07 InnoDB: Started; log sequence number 0 283882395 070508 16:25:07 [Note] Recovering after a crash using adflow-bin 070508 16:25:07 [Note] Starting crash recovery... 070508 16:25:07 [Note] Crash recovery finished. 070508 16:25:07 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 150092672 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070508 16:25:42InnoDB: Assertion failure in thread 2539506608 in file fil0fil.c line 3959 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. 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=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa0b0bd0 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=0x975da9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x9cfde8 0x55493a 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 0xa0d5978 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070508 16:25:42 mysqld restarted 070508 16:25:42 [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=adflow-bin' to avoid this problem. 070508 16:25:42 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... 070508 16:25:42 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 283882405. InnoDB: Doing recovery: scanned up to log sequence number 0 283882405 InnoDB: Last MySQL binlog file position 0 28523, file name ./adflow-bin.000065 070508 16:25:42 InnoDB: Started; log sequence number 0 283882405 070508 16:25:42 [Note] Recovering after a crash using adflow-bin 070508 16:25:42 [Note] Starting crash recovery... 070508 16:25:42 [Note] Crash recovery finished. 070508 16:25:42 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 80952192 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070508 16:25:49InnoDB: Assertion failure in thread 2539518896 in file fil0fil.c line 3959 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. 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=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9b66798 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=0x975dd9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xc69de8 0xbc993a 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 0x974045c8 is invalid pointer 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. Number of processes running now: 0 070508 16:25:49 mysqld restarted 070508 16:25:49 [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=adflow-bin' to avoid this problem. 070508 16:25:49 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... 070508 16:25:49 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 283882405. InnoDB: Doing recovery: scanned up to log sequence number 0 283882415 InnoDB: Last MySQL binlog file position 0 28523, file name ./adflow-bin.000065 070508 16:25:49 InnoDB: Started; log sequence number 0 283882415 070508 16:25:49 [Note] Recovering after a crash using adflow-bin 070508 16:25:49 [Note] Starting crash recovery... 070508 16:25:49 [Note] Crash recovery finished. 070508 16:25:49 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 80952192 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070508 16:26:14InnoDB: Assertion failure in thread 2537216944 in file fil0fil.c line 3959 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. 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=3 max_connections=100 threads_connected=3 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x92fb7a8 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=0x973ab9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xc9fde8 0x77a93a 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 0x936d300 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070508 16:26:14 mysqld restarted 070508 16:26:14 [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=adflow-bin' to avoid this problem. 070508 16:26:14 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... 070508 16:26:14 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 283882843. InnoDB: Doing recovery: scanned up to log sequence number 0 283882843 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000068 070508 16:26:14 InnoDB: Started; log sequence number 0 283882843 070508 16:26:14 [Note] Recovering after a crash using adflow-bin 070508 16:26:14 [Note] Starting crash recovery... 070508 16:26:14 [Note] Crash recovery finished. 070508 16:26:14 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 166542208 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070508 19:22:05InnoDB: Assertion failure in thread 2528852912 in file fil0fil.c line 3959 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. 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=49 max_connections=100 threads_connected=48 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x97095cf8 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=0x96bb19dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xfccde8 0xb8793a 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 0x9c488f8 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=47 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 070508 19:22:05 mysqld restarted 070508 19:22:06 [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=adflow-bin' to avoid this problem. 070508 19:22:06 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... 070508 19:22:06 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 284339117. InnoDB: Doing recovery: scanned up to log sequence number 0 284339117 InnoDB: Last MySQL binlog file position 0 448541, file name ./adflow-bin.000069 070508 19:22:06 InnoDB: Started; log sequence number 0 284339117 070508 19:22:06 [Note] Recovering after a crash using adflow-bin 070508 19:22:06 [Note] Starting crash recovery... 070508 19:22:06 [Note] Crash recovery finished. 070508 19:22:06 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 106773376 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070508 19:22:15InnoDB: Assertion failure in thread 2539719600 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa22e638 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=0x9760e9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 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 0xa256e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070508 19:22:15 mysqld restarted 070508 19:22:15 [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=adflow-bin' to avoid this problem. 070508 19:22:15 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... 070508 19:22:15 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 284339117. InnoDB: Doing recovery: scanned up to log sequence number 0 284339127 InnoDB: Last MySQL binlog file position 0 448541, file name ./adflow-bin.000069 070508 19:22:15 InnoDB: Started; log sequence number 0 284339127 070508 19:22:15 [Note] Recovering after a crash using adflow-bin 070508 19:22:15 [Note] Starting crash recovery... 070508 19:22:15 [Note] Crash recovery finished. 070508 19:22:16 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 170015616 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070508 22:25:29InnoDB: Assertion failure in thread 2539715504 in file fil0fil.c line 3959 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. 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=9 max_connections=100 threads_connected=8 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9cdc638 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=0x9760d9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xf88de8 0x1ed93a 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 0x9d04e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070508 22:25:29 mysqld restarted 070508 22:25:29 [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=adflow-bin' to avoid this problem. 070508 22:25:29 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... 070508 22:25:29 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 284340688. InnoDB: Doing recovery: scanned up to log sequence number 0 284340688 InnoDB: Last MySQL binlog file position 0 1091, file name ./adflow-bin.000071 070508 22:25:29 InnoDB: Started; log sequence number 0 284340688 070508 22:25:29 [Note] Recovering after a crash using adflow-bin 070508 22:25:29 [Note] Starting crash recovery... 070508 22:25:29 [Note] Crash recovery finished. 070508 22:25:29 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 154680192 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070509 8:29:32InnoDB: Assertion failure in thread 2539723696 in file fil0fil.c line 3959 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. 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=23 max_connections=100 threads_connected=23 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9b1c638 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=0x9760f9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 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 0x9cfc600 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=211 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 070509 08:29:32 mysqld restarted 070509 8:29:32 [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=adflow-bin' to avoid this problem. 070509 8:29:32 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... 070509 8:29:33 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 284345751. InnoDB: Doing recovery: scanned up to log sequence number 0 284345751 InnoDB: Last MySQL binlog file position 0 3827, file name ./adflow-bin.000072 070509 8:29:33 InnoDB: Started; log sequence number 0 284345751 070509 8:29:33 [Note] Recovering after a crash using adflow-bin 070509 8:29:33 [Note] Starting crash recovery... 070509 8:29:33 [Note] Crash recovery finished. 070509 8:29:33 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 154680192 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070509 8:35:52InnoDB: Assertion failure in thread 2539707312 in file fil0fil.c line 3959 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. 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=20 max_connections=100 threads_connected=20 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa0f9930 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=0x9760b9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xc9fde8 0x5d793a 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 0xa121e18 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070509 08:35:52 mysqld restarted 070509 8:35:52 [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=adflow-bin' to avoid this problem. 070509 8:35:52 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... 070509 8:35:52 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 284346499. InnoDB: Doing recovery: scanned up to log sequence number 0 284346499 InnoDB: Last MySQL binlog file position 0 646, file name ./adflow-bin.000073 070509 8:35:52 InnoDB: Started; log sequence number 0 284346499 070509 8:35:52 [Note] Recovering after a crash using adflow-bin 070509 8:35:52 [Note] Starting crash recovery... 070509 8:35:52 [Note] Crash recovery finished. 070509 8:35:52 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) 070509 15:18:20 mysqld started 070509 15:18:21 [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=adflow-bin' to avoid this problem. 070509 15:18: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... 070509 15:18:21 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 285225047. InnoDB: Doing recovery: scanned up to log sequence number 0 285225047 InnoDB: Last MySQL binlog file position 0 811846, file name ./adflow-bin.000074 070509 15:18:22 InnoDB: Started; log sequence number 0 285225047 070509 15:18:22 [Note] Recovering after a crash using adflow-bin 070509 15:18:22 [Note] Starting crash recovery... 070509 15:18:22 [Note] Crash recovery finished. 070509 15:18:22 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 143473536 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 13:54:15InnoDB: Assertion failure in thread 2527640496 in file fil0fil.c line 3959 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. 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=67 max_connections=100 threads_connected=55 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x92b2818 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=0x96a899dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x1e8de8 0x32393a 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 0x92b5ca0 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=3554 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 070514 13:54:16 mysqld restarted 070514 13:54:16 [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=adflow-bin' to avoid this problem. 070514 13:54:16 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... 070514 13:54:16 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288881903. InnoDB: Doing recovery: scanned up to log sequence number 0 288881903 InnoDB: Last MySQL binlog file position 0 3282356, file name ./adflow-bin.000075 070514 13:54:16 InnoDB: Started; log sequence number 0 288881903 070514 13:54:16 [Note] Recovering after a crash using adflow-bin 070514 13:54:16 [Note] Starting crash recovery... 070514 13:54:16 [Note] Crash recovery finished. 070514 13:54:16 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 143473536 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 13:54:21InnoDB: Assertion failure in thread 2539711408 in file fil0fil.c line 3959 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. 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=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8b2b638 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=0x9760c9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x55ade8 0x1ed93a 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 0x8b53e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070514 13:54:21 mysqld restarted 070514 13:54:21 [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=adflow-bin' to avoid this problem. 070514 13:54: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... 070514 13:54:21 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288881903. InnoDB: Doing recovery: scanned up to log sequence number 0 288881913 InnoDB: Last MySQL binlog file position 0 3282356, file name ./adflow-bin.000075 070514 13:54:21 InnoDB: Started; log sequence number 0 288881913 070514 13:54:21 [Note] Recovering after a crash using adflow-bin 070514 13:54:21 [Note] Starting crash recovery... 070514 13:54:21 [Note] Crash recovery finished. 070514 13:54:21 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 58407808 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 14:56:19InnoDB: Assertion failure in thread 2535504816 in file fil0fil.c line 3959 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. 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=100 threads_connected=24 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x96d4860 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=0x972099dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x1e9de8 0x4d093a 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 0x96f8f38 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=58 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 070514 14:56:19 mysqld restarted 070514 14:56:19 [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=adflow-bin' to avoid this problem. 070514 14:56:19 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... 070514 14:56:19 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288892461. InnoDB: Doing recovery: scanned up to log sequence number 0 288892461 InnoDB: Last MySQL binlog file position 0 9074, file name ./adflow-bin.000077 070514 14:56:19 InnoDB: Started; log sequence number 0 288892461 070514 14:56:19 [Note] Recovering after a crash using adflow-bin 070514 14:56:19 [Note] Starting crash recovery... 070514 14:56:19 [Note] Crash recovery finished. 070514 14:56:19 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 31079296 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 14:56:29InnoDB: Assertion failure in thread 2539707312 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8f37638 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=0x9760b9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x3ebde8 0x2e693a 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 0x8f5fe68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070514 14:56:29 mysqld restarted 070514 14:56:29 [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=adflow-bin' to avoid this problem. 070514 14:56:29 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... 070514 14:56:29 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288892500. InnoDB: Doing recovery: scanned up to log sequence number 0 288892510 InnoDB: Last MySQL binlog file position 0 9074, file name ./adflow-bin.000077 070514 14:56:29 InnoDB: Started; log sequence number 0 288892510 070514 14:56:29 [Note] Recovering after a crash using adflow-bin 070514 14:56:29 [Note] Starting crash recovery... 070514 14:56:29 [Note] Crash recovery finished. 070514 14:56:29 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 101399424 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 14:56:35InnoDB: Assertion failure in thread 2539723696 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa482638 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=0x9760f9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 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 0xa4aae68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070514 14:56:35 mysqld restarted 070514 14:56:35 [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=adflow-bin' to avoid this problem. 070514 14:56:35 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... 070514 14:56:35 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288892510. InnoDB: Doing recovery: scanned up to log sequence number 0 288892520 InnoDB: Last MySQL binlog file position 0 9074, file name ./adflow-bin.000077 070514 14:56:35 InnoDB: Started; log sequence number 0 288892520 070514 14:56:35 [Note] Recovering after a crash using adflow-bin 070514 14:56:35 [Note] Starting crash recovery... 070514 14:56:35 [Note] Crash recovery finished. 070514 14:56:36 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8adf308 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=0x974ca0bc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x82b5346 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x5e4de8 0x85993a 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 0x8b07b38 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070514 14:56:36 mysqld restarted 070514 14:56:36 [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=adflow-bin' to avoid this problem. 070514 14:56:36 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... 070514 14:56:36 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288892510. InnoDB: Doing recovery: scanned up to log sequence number 0 288892520 InnoDB: Last MySQL binlog file position 0 9074, file name ./adflow-bin.000077 070514 14:56:36 InnoDB: Started; log sequence number 0 288892520 070514 14:56:36 [Note] Recovering after a crash using adflow-bin 070514 14:56:36 [Note] Starting crash recovery... 070514 14:56:36 [Note] Crash recovery finished. 070514 14:56:36 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 101399424 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 14:56:41InnoDB: Assertion failure in thread 2539715504 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9c5a638 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=0x9760d9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xabede8 0x2f893a 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 0x9c82e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070514 14:56:41 mysqld restarted 070514 14:56:41 [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=adflow-bin' to avoid this problem. 070514 14:56:42 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... 070514 14:56:42 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288892520. InnoDB: Doing recovery: scanned up to log sequence number 0 288892530 InnoDB: Last MySQL binlog file position 0 9074, file name ./adflow-bin.000077 070514 14:56:42 InnoDB: Started; log sequence number 0 288892530 070514 14:56:42 [Note] Recovering after a crash using adflow-bin 070514 14:56:42 [Note] Starting crash recovery... 070514 14:56:42 [Note] Crash recovery finished. 070514 14:56:42 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 101399424 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 14:57:04InnoDB: Assertion failure in thread 2538458032 in file fil0fil.c line 3959 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. 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=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x95be9f8 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=0x974da9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x61cde8 0xbaf93a 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 0x95ed0b0 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070514 14:57:04 mysqld restarted 070514 14:57: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=adflow-bin' to avoid this problem. 070514 14:57:05 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... 070514 14:57:05 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288893322. InnoDB: Doing recovery: scanned up to log sequence number 0 288893322 InnoDB: Last MySQL binlog file position 0 930, file name ./adflow-bin.000082 070514 14:57:05 InnoDB: Started; log sequence number 0 288893322 070514 14:57:05 [Note] Recovering after a crash using adflow-bin 070514 14:57:05 [Note] Starting crash recovery... 070514 14:57:05 [Note] Crash recovery finished. 070514 14:57:05 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) 070514 15:01:52070514 15:01:52 InnoDB: Page dump in ascii and hex (16384 bytes): len 16384; hex 7ea7a054000038880000388700003889000000000de5003545bf00000000000000000000000000633b1a818d0000000000000002018a018b0000000000000000000000000000000000b02d616c69676e3a206d6964646c653b7d0a090909010002001a696e66696d756d0008000b000073757072656d756d00001000268000000000001b2d0000000308a2800000002d0110800000118000123ebf8fe34400001800268000000000001b2e0000000308a3800000002d0110800000348000123ebf8fe88f00002000268000000000001b2f0000000308a4800000002d01108000004b8000123ebf8fef0c04002800268000000000001b300000000308a5800000002d0110800000248000123ebf8ff11b00003000268000000000001b310000000308a6800000002d01108000005e8000123ebf8ff5d200003800268000000000001b320000000308a7800000002d01108000002f8000123ebf900f2a00004000268000000000001b330000000308a8800000002d01108000003b8000123ebf9011bd04004800268000000000001b340000000308a9800000002d0110800000648000123ebf90129200005000268000000000001b350000000308aa800000002d01108000004b8000123ebf9012a100005800268000000000001b360000000308ab800000002d0110800000658000123ebf90176400006000268000000000001b370000000308ac800000002d01108000002f8000123ebf901d8f04006800268000000000001b380000000308ad800000002d01108000004b8000123ebf901ed500007000268000000000001b390000000308ae800000002d0110800000678000123ebf9030c900007800268000000000001b3a0000000308af800000002d01108000002f8000123ebf90311c00008000268000000000001b3b0000000308b0800000002d01108000004b8000123ebf90319104008800268000000000001b3c0000000308b1800000002d0110800000458000123ebf90375c00009000268000000000001b3d0000000308b2800000002d0110800000458000123ebf903b4f00009800268000000000001b3e0000000308b3800000002d0110800000038000123ebf9042be0000a000268000000000001b3f0000000308b4800000002d0110800000138000123ebf9043e80400a800268000000000001b400000000308b5800000002d01108000002e8000123ebf90a8580000b000268000000000001b410000000308b6800000002d0110800000368000123ebf9e17ac0000b800268000000000001b420000000308b7800000002d0110800000658000123ebf9e1b260000c000268000000000001b430000000308b8800000002d0110800000628000123ebf9e1d220400c800268000000000001b440000000308b9800000002d01108000002f8000123ebf9e21280000d000268000000000001b450000000308ba800000002d0110800000648000123ebf9e21ee0000d800268000000000001b460000000308bb800000002d0110800000078000123ebf9e22a30000e000268000000000001b470000000308bc800000002d0110800000678000123ebf9e25070400e800268000000000001b480000000308bd800000002d0110800000668000123ebf9e250f0000f000268000000000001b490000000308be800000002d0110800000378000123ebf9e255d0000f800268000000000001b4a0000000308bf800000002d0110800000438000123ebf9e282900010000268000000000001b4b0000000308c0800000002d01108000001d8000123ebf9e3a2a04010800268000000000001b4c0000000308c1800000002d0110800000688000123ebf9e3ba300011000268000000000001b4d0000000308c2800000002d0110800000278000123ebf9e3f9000011800268000000000001b4e0000000308c3800000002d0110800000388000123ebf9e3f9400012000268000000000001b4f0000000308c4800000002d0110800000228000123ebf9e422a04012800268000000000001b500000000308c5800000002d0110800000038000123ebf9e44ac00013000268000000000001b510000000308c6800000002d0110800000138000123ebf9e451a00013800268000000000001b520000000308c7800000002d0110800000438000123ebf9e49b100014000268000000000001b530000000308c8800000002d0110800000608000123ebf9e4b2a04014800268000000000001b540000000308c9800000002d0110800000608000123ebf9e4baa00015000268000000000001b550000000308ca800000002d0110800000138000123ebf9e4d4800015800268000000000001b560000000308cb800000002d0110800000438000123ebf9e61fd00016000268000000000001b570000000308cc800000002d0110800000458000123ebf9e6e1a04016800268000000000001b580000000308cd800000002d0110800000648000123ebf9e6f1800017000268000000000001b590000000308ce800000002d0110800000658000123ebf9e74bb00017800268000000000001b5a0000000308cf800000002d0110800000138000123ebf9e75ec00018000268000000000001b5b0000000308d0800000002d0110800000458000123ebf9e87c204018800268000000000001b5c0000000308d1800000002d0110800000438000123ebf9ec18400019000268000000000001b5d0000000308d2800000002d01108000004b8000123ebf9edb6800019800268000000000001b5e0000000308d3800000002d0110800000278000123ebf9edc8b0001a000268000000000001b5f0000000308d4800000002d0110800000168000123ebf9eded30401a800268000000000001b600000000308d5800000002d01108000001d8000123ebf9edfab0001b000268000000000001b610000000308d6800000002d01108000005e8000123ebf9ee0e50001b800268000000000001b620000000308d7800000002d0110800000228000123ebf9ee2130001c000268000000000001b630000000308d8800000002d0110800000348000123ebf9ee27b0401c800268000000000001b640000000308d9800000002d0110800000118000123ebf9ee3b30001d000268000000000001b650000000308da800000002d0110800000128000123ebf9ee53e0001d800268000000000001b660000000308db800000002d01108000005e8000123ebf9ee7680001e000268000000000001b670000000308dc800000002d0110800000138000123ebf9efdd30401e800268000000000001b680000000308dd800000002d01108000003b8000123ebf9effbd0001f000268000000000001b690000000308de800000002d01108000004b8000123ebf9f00f10001f800268000000000001b6a0000000308df800000002d0110800000348000123ebf9f03bc00020000268000000000001b6b0000000308e0800000002d0110800000348000123ebf9f040304020800268000000000001b6c0000000308e1800000002d0110800000458000123ebf9f047a00021000268000000000001b6d0000000308e2800000002d0110800000048000123ebf9f05a800021800268000000000001b6e0000000308e3800000002d0110800000348000123ebf9f05ec00022000268000000000001b6f0000000308e4800000002d0110800000118000123ebf9f089c04022800268000000000001b700000000308e5800000002d0110800000118000123ebf9f0cef00023000268000000000001b710000000308e6800000002d0110800000348000123ebf9f132e00023800268000000000001b720000000308e7800000002d0110800000138000123ebf9f139c00024000268000000000001b730000000308e8800000002d01108000002f8000123ebf9f291004024800268000000000001b740000000308e9800000002d0110800000138000123ebf9f2d1000025000268000000000001b750000000308ea800000002d0110800000648000123ebf9f314700025800268000000000001b760000000308eb800000002d0110800000048000123ebf9f380500026000268000000000001b770000000308ec800000002d0110800000138000123ebf9f535404026800268000000000001b780000000308ed800000002d01108000003b8000123ebf9f54e900027000268000000000001b790000000308ee800000002d01108000003c8000123ebf9f556300027800268000000000001b7a0000000308ef800000002d01108000001d8000123ebf9f574900028000268000000000001b7b0000000308f0800000002d0110800000388000123ebf9f5b3f04028800268000000000001b7c0000000308f1800000002d0110800000388000123ebf9f5bcd00029000268000000000001b7d0000000308f2800000002d0110800000388000123ebf9f5bcf00029800268000000000001b7e0000000308f3800000002d0110800000278000123ebf9f778b0002a000268000000000001b7f0000000308f4800000002d0110800000668000123ebf9f7ab10402a800268000000000001b800000000308f5800000002d0110800000348000123ebf9f81770002b000268000000000001b810000000308f6800000002d0110800000648000123ebf9f892f0002b800268000000000001b820000000308f7800000002d0110800000628000123ebf9f89470002c000268000000000001b830000000308f8800000002d0110800000658000123ebf9f9b930402c800268000000000001b840000000308f9800000002d0110800000118000123ebf9f9e530002d000268000000000001b850000000308fa800000002d0110800000138000123ebf9f9f250002d800268000000000001b860000000308fb800000002d0110800000458000123ebf9fa48f0002e000268000000000001b870000000308fc800000002d0110800000458000123ebf9fc4810402e800268000000000001b880000000308fd800000002d01108000004b8000123ebf9fc5c90002f000268000000000001b890000000308fe800000002d0110800000128000123ebf9fc92c0002f800268000000000001b8a0000000308ff800000002d0110800000458000123ebf9fcc7a00030000268000000000001b8b000000030900800000002d0110800000458000123ebf9fec7904030800268000000000001b8c000000030901800000002d01108000005e8000123ebfa03ed000031000268000000000001b8d000000030902800000002d0110800000078000123ebfad592300031800268000000000001b8e000000030903800000002d0110800000368000123ebfad5c5a00032000268000000000001b8f000000030904800000002d0110800000658000123ebfad5fdb04032800268000000000001b90000000030905800000002d01108000002f8000123ebfad614d00033000268000000000001b91000000030906800000002d0110800000138000123ebfad691100033800268000000000001b92000000030907800000002d0110800000038000123ebfad6aca00034000268000000000001b93000000030908800000002d0110800000678000123ebfad6b0c04034800268000000000001b94000000030909800000002d01108000005e8000123ebfad809e00035000268000000000001b9500000003090a800000002d0110800000138000123ebfad80a300035800268000000000001b9600000003090b800000002d0110800000378000123ebfad827c00036000268000000000001b9700000003090c800000002d0110800000668000123ebfad830304036800268000000000001b9800000003090d800000002d0110800000628000123ebfad836300037000268000000000001b9900000003090e800000002d0110800000688000123ebfad853d00037800268000000000001b9a00000003090f800000002d0110800000648000123ebfad856500038000268000000000001b9b000000030910800000002d0110800000128000123ebfad867404038800268000000000001b9c000000030911800000002d0110800000438000123ebfad88d000039000268000000000001b9d000000030912800000002d0110800000048000123ebfad8b4500039800268000000000001b9e000000030913800000002d01108000003b8000123ebfad8d1a0003a000268000000000001b9f000000030914800000002d0110800000648000123ebfad8e4d0403a800268000000000001ba0000000030915800000002d0110800000278000123ebfad8ea90003b000268000000000001ba1000000030916800000002d0110800000628000123ebfad8eab0003b800268000000000001ba2000000030917800000002d0110800000628000123ebfad90b10003c000268000000000001ba3000000030918800000002d0110800000168000123ebfada2eb0403c800268000000000001ba4000000030919800000002d01108000005e8000123ebfada6290003d000268000000000001ba500000003091a800000002d0110800000138000123ebfada6960003d800268000000000001ba600000003091b800000002d0110800000048000123ebfadab970003e000268000000000001ba700000003091c800000002d0110800000138000123ebfadb1d40403e800268000000000001ba800000003091d800000002d0110800000348000123ebfadb7b80003f000268000000000001ba900000003091e800000002d0110800000018000123ebfadb82f0003f800268000000000001baa00000003091f800000002d0110800000388000123ebfadb87c00040000268000000000001bab000000030920800000002d0110800000118000123ebfadcd4404040800268000000000001bac000000030921800000002d01108000004b8000123ebfadced500041000268000000000001bad000000030922800000002d0110800000648000123ebfadd03500041800268000000000001bae000000030923800000002d0110800000688000123ebfadd0b700042000268000000000001baf000000030924800000002d0110800000278000123ebfadd55104042800268000000000001bb0000000030925800000002d0110800000648000123ebfae006600043000268000000000001bb1000000030926800000002d0110800000118000123ebfae056700043800268000000000001bb2000000030927800000002d0110800000458000123ebfae19ce00044000268000000000001bb3000000030928800000002d0110800000628000123ebfae1a7a04044800268000000000001bb4000000030929800000002d0110800000128000123ebfae1aa100045000268000000000001bb500000003092a800000002d0110800000628000123ebfae1b5000045800268000000000001bb600000003092b800000002d0110800000048000123ebfae1dba00046000268000000000001bb700000003092c800000002d0110800000628000123ebfae1eb504046800268000000000001bb800000003092d800000002d0110800000118000123ebfae1edf00047000268000000000001bb900000003092e800000002d0110800000228000123ebfae217700047800268000000000001bba00000003092f800000002d0110800000138000123ebfae231400048000268000000000001bbb000000030930800000002d0110800000128000123ebfae243904048800268000000000001bbc000000030931800000002d0110800000688000123ebfae25e200049000268000000000001bbd000000030932800000002d0110800000628000123ebfae2a3600049800268000000000001bbe000000030933800000002d0110800000378000123ebfae2b9d0004a000268000000000001bbf000000030934800000002d0110800000648000123ebfae2e180404a800268000000000001bc0000000030935800000002d0110800000138000123ebfae45280004b000268000000000001bc1000000030936800000002d0110800000648000123ebfae49e30004b800268000000000001bc2000000030937800000002d0110800000048000123ebfae4e880004c000268000000000001bc3000000030938800000002d0110800000648000123ebfae4fc20404c800268000000000001bc4000000030939800000002d0110800000138000123ebfae50010004d000268000000000001bc500000003093a800000002d0110800000458000123ebfae551f0004d800268000000000001bc600000003093b800000002d0110800000388000123ebfae6c780004e000268000000000001bc700000003093c800000002d0110800000648000123ebfae70900404e800268000000000001bc800000003093d800000002d0110800000048000123ebfae72b10004f000268000000000001bc900000003093e800000002d0110800000128000123ebfae9e350004f800268000000000001bca00000003093f800000002d0110800000458000123ebfaeba9c00050000268000000000001bcb000000030940800000002d0110800000628000123ebfaebb6304050800268000000000001bcc000000030941800000002d0110800000278000123ebfaec00a00051000268000000000001bcd000000030942800000002d01108000004b8000123ebfaec21f00051800268000000000001bce000000030943800000002d01108000005e8000123ebfaeca3a00052000268000000000001bcf000000030944800000002d0110800000348000123ebfaedbf304052800268000000000001bd0000000030945800000002d01108000002f8000123ebfaee1b100053000268000000000001bd1000000030946800000002d0110800000018000123ebfaee6be00053800268000000000001bd2000000030947800000002d01108000005e8000123ebfaf04f800054000268000000000001bd3000000030948800000002d01108000005e8000123ebfaf11b504054800268000000000001bd4000000030949800000002d01108000005e8000123ebfaf2cd400055000268000000000001bd500000003094a800000002d01108000004b8000123ebfaf50c600055800268000000000001bd600000003094b800000002d0110800000368000123ebfbca0df00056000268000000000001bd700000003094c800000002d0110800000658000123ebfbca0f004056800268000000000001bd800000003094d800000002d0110800000078000123ebfbca0f700057000268000000000001bd900000003094e800000002d0110800000628000123ebfbca53f00057800268000000000001bda00000003094f800000002d0110800000378000123ebfbca64700058000268000000000001bdb000000030950800000002d0110800000018000123ebfbca98804058800268000000000001bdc000000030951800000002d0110800000648000123ebfbca99300059000268000000000001bdd000000030952800000002d0110800000018000123ebfbcaa3e00059800268000000000001bde000000030953800000002d01108000005e8000123ebfbcac9a0005a000268000000000001bdf000000030954800000002d0110800000678000123ebfbcc1af0405a800268000000000001be0000000030955800000002d0110800000388000123ebfbcc2050005b000268000000000001be1000000030956800000002d0110800000688000123ebfbcc2870005b800268000000000001be2000000030957800000002d0110800000138000123ebfbcc2e80005c000268000000000001be3000000030958800000002d0110800000628000123ebfbcc2fa0405c800268000000000001be4000000030959800000002d0110800000138000123ebfbcc6b70005d000268000000000001be500000003095a800000002d0110800000278000123ebfbcc8d30005d800268000000000001be600000003095b800000002d01108000004b8000123ebfbcc9880005e000268000000000001be700000003095c800000002d01108000005e8000123ebfbcc9920405e800268000000000001be800000003095d800000002d01108000005e8000123ebfbccd540005f000268000000000001be900000003095e800000002d0110800000688000123ebfbccd5b0005f800268000000000001bea00000003095f800000002d01108000004b8000123ebfbcd28e00060000268000000000001beb000000030960800000002d0110800000168000123ebfbcd2d304060800268000000000001bec000000030961800000002d0110800000168000123ebfbcd35800061000268000000000001bed000000030962800000002d01108000003b8000123ebfbce53500061800268000000000001bee000000030963800000002d0110800000128000123ebfbce54100062000268000000000001bef000000030964800000002d01108000005e8000123ebfbce72304062800268000000000001bf0000000030965800000002d0110800000078000123ebfbce7fb00063000268000000000001bf1000000030966800000002d0110800000688000123ebfbce84c00063800268000000000001bf2000000030967800000002d0110800000348000123ebfbcea4e00064000268000000000001bf3000000030968800000002d01108000002f8000123ebfbceaca04064800268000000000001bf4000000030969800000002d01108000002f8000123ebfbced1100065000268000000000001bf500000003096a800000002d01108000003b8000123ebfbcf10200065800268000000000001bf600000003096b800000002d0110800000348000123ebfbcf10600066000268000000000001bf700000003096c800000002d01108000005e8000123ebfbcf42304066800268000000000001bf800000003096d800000002d01108000005e8000123ebfbcf6e800067000268000000000001bf900000003096e800000002d01108000005e8000123ebfbcfa6c00067800268000000000001bfa00000003096f800000002d0110800000128000123ebfbcfad200068000268000000000001bfb000000030970800000002d0110800000128000123ebfbd188604068800268000000000001bfc000000030971800000002d0110800000678000123ebfbd227500069000268000000000001bfd000000030972800000002d0110800000018000123ebfbd469e00069800268000000000001bfe000000030973800000002d0110800000348000123ebfbd5ade0006a000268000000000001bff000000030974800000002d0110800000348000123ebfbd5fd40406a800268000000000001c00000000030975800000002d0110800000348000123ebfbd612a0006b000268000000000001c01000000030976800000002d0110800000078000123ebfbd62b50006b800268000000000001c02000000030977800000002d01108000005e8000123ebfbd66930006c000268000000000001c03000000030978800000002d01108000004c8000123ebfbd6b8c0406c800268000000000001c04000000030979800000002d0110800000038000123ebfbd6be80006d000268000000000001c0500000003097a800000002d01108000004b8000123ebfbd6d2c0006d800268000000000001c0600000003097b800000002d0110800000128000123ebfbd703d0006e000268000000000001c0700000003097c800000002d0110800000128000123ebfbd71760406e800268000000000001c0800000003097d800000002d0110800000128000123ebfbd82300006f000268000000000001c0900000003097e800000002d0110800000128000123ebfbd83650006f800268000000000001c0a00000003097f800000002d0110800000648000123ebfbd838100070000268000000000001c0b000000030980800000002d0110800000438000123ebfbd88d104070800268000000000001c0c000000030981800000002d01108000005e8000123ebfbd899e00071000268000000000001c0d000000030982800000002d0110800000128000123ebfbd8a1000071800268000000000001c0e000000030983800000002d0110800000128000123ebfbd8c2100072000268000000000001c0f000000030984800000002d0110800000128000123ebfbd8d1804072800268000000000001c10000000030985800000002d01108000005e8000123ebfbd90c100073000268000000000001c11000000030986800000002d0110800000118000123ebfbd913300073800268000000000001c12000000030987800000002d0110800000628000123ebfbd91c800074000268000000000001c13000000030988800000002d01108000004b8000123ebfbd91eb04074800268000000000001c14000000030989800000002d01108000005e8000123ebfbd970200075000268000000000001c1500000003098a800000002d01108000005e8000123ebfbdb04f00075800268000000000001c1600000003098b800000002d0110800000658000123ebfbdb3db00076000268000000000001c1700000003098c800000002d0110800000048000123ebfbdbe5e04076800268000000000001c1800000003098d800000002d0110800000348000123ebfbdd13900077000268000000000001c1900000003098e800000002d0110800000348000123ebfbdd1f400077800268000000000001c1a00000003098f800000002d01108000004b8000123ebfbdd97d00078000268000000000001c1b000000030990800000002d0110800000348000123ebfbdda9e04078800268000000000001c1c000000030991800000002d0110800000018000123ebfbddcca00079000268000000000001c1d000000030992800000002d0110800000048000123ebfbde07600079800268000000000001c1e000000030993800000002d0110800000278000123ebfbde3fe0007a000268000000000001c1f000000030994800000002d0110800000168000123ebfbdfa300407a800268000000000001c20000000030995800000002d01108000005e8000123ebfbdfc8b0007b000268000000000001c21000000030996800000002d0110800000278000123ebfbdfd090007b800268000000000001c22000000030997800000002d0110800000138000123ebfbdfe0e0007c000268000000000001c23000000030998800000002d0110800000138000123ebfbdff370407c800268000000000001c24000000030999800000002d0110800000278000123ebfbe018e0007d000268000000000001c2500000003099a800000002d01108000003c8000123ebfbe026e0007d800268000000000001c2600000003099b800000002d0110800000018000123ebfbe02800007e000268000000000001c2700000003099c800000002d0110800000668000123ebfbe059b0407e800268000000000001c2800000003099d800000002d01108000005e8000123ebfbe260b0007f000268000000000001c2900000003099e800000002d0110800000368000123ebfbe27270007f800268000000000001c2a00000003099f800000002d0110800000138000123ebfbe31f300080000268000000000001c2b0000000309a0800000002d0110800000348000123ebfbe80ea04080800268000000000001c2c0000000309a1800000002d0110800000348000123ebfbe97aa00081000268000000000001c2d0000000309a2800000002d01108000002f8000123ebff9a2ec00081800268000000000001c2e0000000309a3800000002d0110800000228000123ebff9a6b400082000268000000000001c2f0000000309a4800000002d0110800000658000123ebff9a7e504082800268000000000001c300000000309a5800000002d0110800000628000123ebff9abc000083000268000000000001c310000000309a6800000002d0110800000668000123ebff9ad7400083800268000000000001c320000000309a7800000002d01108000004b8000123ebff9adaf00084000268000000000001c330000000309a8800000002d01108000002f8000123ebff9ae8904084800268000000000001c340000000309a9800000002d0110800000378000123ebff9ae9400085000268000000000001c350000000309aa800000002d0110800000078000123ebff9af6b00085800268000000000001c360000000309ab800000002d0110800000388000123ebff9af6f00086000268000000000001c370000000309ac800000002d0110800000438000123ebff9b02104086800268000000000001c380000000309ad800000002d0110800000458000123ebff9b1a900087000268000000000001c390000000309ae800000002d01108000005e8000123ebff9b1ac00087800268000000000001c3a0000000309af800000002d01108000001d8000123ebff9b1ad00088000268000000000001c3b0000000309b0800000002d0110800000648000123ebff9b5fa04088800268000000000001c3c0000000309b1800000002d0110800000348000123ebff9c9cc00089000268000000000001c3d0000000309b2800000002d0110800000168000123ebff9ca5000089800268000000000001c3e0000000309b3800000002d0110800000278000123ebff9cb2b0008a000268000000000001c3f0000000309b4800000002d0110800000138000123ebff9cdc70408a800268000000000001c400000000309b5800000002d01108000005e8000123ebff9ce490008b000268000000000001c410000000309b6800000002d0110800000688000123ebff9ceb10008b800268000000000001c420000000309b7800000002d0110800000628000123ebff9d8030008c000268000000000001c430000000309b8800000002d0110800000078000123ebff9db1d0408c800268000000000001c440000000309b9800000002d01108000004c8000123ebff9ef870008d000268000000000001c450000000309ba800000002d0110800000688000123ebff9f04b0008d800268000000000001c460000000309bb800000002d01108000003b8000123ebff9f6b90008e000268000000000001c470000000309bc800000002d0110800000018000123ebff9f78d0408e800268000000000001c480000000309bd800000002d01108000002e8000123ebff9fa480008f000268000000000001c490000000309be800000002d0110800000608000123ebff9fac90008f800268000000000001c4a0000000309bf800000002d0110800000608000123ebff9fbe800090000268000000000001c4b0000000309c0800000002d0110800000118000123ebff9fc6804090800268000000000001c4c0000000309c1800000002d01108000005e8000123ebff9fd0800091000268000000000001c4d0000000309c2800000002d01108000001c8000123ebff9fd1100091800268000000000001c4e0000000309c3800000002d0110800000368000123ebff9fdc900092000268000000000001c4f0000000309c4800000002d01108000004b8000123ebffa022d04092800268000000000001c500000000309c5800000002d01108000003c8000123ebffa03d100093000268000000000001c510000000309c6800000002d01108000003b8000123ebffa042800093800268000000000001c520000000309c7800000002d0110800000348000123ebffa153300094000268000000000001c530000000309c8800000002d0110800000038000123ebffa178804094800268000000000001c540000000309c9800000002d01108000005e8000123ebffa17f000095000268000000000001c550000000309ca800000002d0110800000348000123ebffa222900095800268000000000001c560000000309cb800000002d0110800000348000123ebffa29f700096000268000000000001c570000000309cc800000002d0110800000048000123ebffa444204096800268000000000001c580000000309cd800000002d0110800000348000123ebffa4a0f00097000268000000000001c590000000309ce800000002d0110800000348000123ebffa4eb300097800268000000000001c5a0000000309cf800000002d0110800000138000123ebffa4f3900098000268000000000001c5b0000000309d0800000002d0110800000628000123ebffa670704098800268000000000001c5c0000000309d1800000002d01108000002f8000123ebffa683100099000268000000000001c5d0000000309d2800000002d0110800000038000123ebffa683700099800268000000000001c5e0000000309d3800000002d0110800000348000123ebffa68760009a000268000000000001c5f0000000309d4800000002d0110800000628000123ebffa69440409a800268000000000001c600000000309d5800000002d01108000002f8000123ebffa69b80009b000268000000000001c610000000309d6800000002d0110800000648000123ebffa6c540009b800268000000000001c620000000309d7800000002d0110800000128000123ebffa6ea40009c000268000000000001c630000000309d8800000002d01108000005e8000123ebffa705a0409c800268000000000001c640000000309d9800000002d0110800000668000123ebffa705e0009d000268000000000001c650000000309da800000002d0110800000348000123ebffa71d90009d800268000000000001c660000000309db800000002d01108000002f8000123ebffa738d0009e000268000000000001c670000000309dc800000002d0110800000688000123ebffa73d30409e800268000000000001c680000000309dd800000002d01108000004b8000123ebffa755b0009f000268000000000001c690000000309de800000002d0110800000388000123ebffa8de90009f800268000000000001c6a0000000309df800000002d0110800000648000123ebffa91ea000a0000268000000000001c6b0000000309e0800000002d0110800000138000123ebffa9238040a0800268000000000001c6c0000000309e1800000002d0110800000018000123ebffa92ad000a1000268000000000001c6d0000000309e2800000002d0110800000048000123ebffa9526000a1800268000000000001c6e0000000309e3800000002d0110800000278000123ebffa9636000a2000268000000000001c6f0000000309e4800000002d0110800000678000123ebffa9dbc040a2800268000000000001c700000000309e5800000002d01108000005e8000123ebffab8e4000a3000268000000000001c710000000309e6800000002d0110800000138000123ebffac112000a3800268000000000001c720000000309e7800000002d0110800000038000123ebffac5ca000a4000268000000000001c730000000309e8800000002d0110800000658000123ebffac65f040a4800268000000000001c740000000309e9800000002d01108000005e8000123ebffac68a000a5000268000000000001c750000000309ea800000002d0110800000048000123ebffadcf9000a5800268000000000001c760000000309eb800000002d0110800000648000123ebffade1c000a6000268000000000001c770000000309ec800000002d0110800000278000123ebffae009040a6800268000000000001c780000000309ed800000002d0110800000688000123ebffae20c000a7000268000000000001c790000000309ee800000002d0110800000658000123ebffae2ab000a7800268000000000001c7a0000000309ef800000002d01108000003b8000123ebffae39a000a8000268000000000001c7b0000000309f0800000002d0110800000648000123ebffae7be040a8800268000000000001c7c0000000309f1800000002d0110800000128000123ebffb02d1000a9000268000000000001c7d0000000309f2800000002d0110800000628000123ebffb065d000a9800268000000000001c7e0000000309f3800000002d0110800000458000123ebffb06a7000aa000268000000000001c7f0000000309f4800000002d01108000005e8000123ebffb07f4040aa800268000000000001c800000000309f5800000002d0110800000018000123ebffb09b9000ab000268000000000001c810000000309f6800000002d01108000005e8000123ebffb0c15000ab800268000000000001c820000000309f7800000002d0110800000688000123ebffb151b000ac000268000000000001c830000000309f8800000002d0110800000348000123ebffb2a4d040ac800268000000000001c840000000309f9800000002d0110800000128000123ebffb2b6b000ad000268000000000001c850000000309fa800000002d0110800000128000123ebffb2d49000ad800268000000000001c860000000309fb800000002d0110800000088000123ebffb2de1000ae000268000000000001c870000000309fc800000002d0110800000128000123ebffb2e87040ae800268000000000001c880000000309fd800000002d01108000005e8000123ebffb2ee6000af000268000000000001c890000000309fe800000002d0110800000348000123ebffb3d15000af800268000000000001c8a0000000309ff800000002d0110800000688000123ebffb5358000b0000268000000000001c8b000000030a00800000002d01108000005e8000123ebffb7d74040b0800268000000000001c8c000000030a01800000002d0110800000128000123ec007f86e000b1000268000000000001c8d000000030a02800000002d0110800000658000123ec008eb6c000b1800268000000000001c8e000000030a03800000002d0110800000458000123ec008ed05000b2000268000000000001c8f000000030a04800000002d0110800000368000123ec008ed3a040b2800268000000000001c90000000030a05800000002d01108000002f8000123ec008ee6b000b3000268000000000001c91000000030a06800000002d0110800000688000123ec008ee92000b3800268000000000001c92000000030a07800000002d0110800000668000123ec008ef9d000b4000268000000000001c93000000030a08800000002d0110800000348000123ec008efbc040b4800268000000000001c94000000030a09800000002d01108000001d8000123ec008f1f3000b5000268000000000001c95000000030a0a800000002d0110800000628000123ec008f209000b5800268000000000001c96000000030a0b800000002d0110800000648000123ec008f45d000b6000268000000000001c97000000030a0c800000002d0110800000628000123ec008f534040b6800268000000000001c98000000030a0d800000002d0110800000378000123ec008f633000b7000268000000000001c99000000030a0e800000002d01108000004b8000123ec008f76d000b7800268000000000001c9a000000030a0f800000002d0110800000668000123ec008f7dc000b8000268000000000001c9b000000030a10800000002d0110800000628000123ec008f7e3040b8800268000000000001c9c000000030a11800000002d0110800000678000123ec008f90f000b9000268000000000001c9d000000030a12800000002d0110800000388000123ec008f978000b9800268000000000001c9e000000030a13800000002d01108000002f8000123ec0090954000ba000268000000000001c9f000000030a14800000002d0110800000078000123ec00909cc040ba800268000000000001ca0000000030a15800000002d0110800000128000123ec0090bb0000bb000268000000000001ca1000000030a16800000002d0110800000648000123ec0090c2b000bb800268000000000001ca2000000030a17800000002d0110800000128000123ec00910c5000bc000268000000000001ca3000000030a18800000002d0110800000128000123ec00912d7040bc800268000000000001ca4000000030a19800000002d0110800000438000123ec00912dd000bd000268000000000001ca5000000030a1a800000002d0110800000118000123ec0091655000bd800268000000000001ca6000000030a1b800000002d01108000005e8000123ec00919e6000be000268000000000001ca7000000030a1c800000002d01108000005e8000123ec0091b0b040be800268000000000001ca8000000030a1d800000002d0110800000458000123ec0091c24000bf000268000000000001ca9000000030a1e800000002d0110800000018000123ec0091e0a000bf800268000000000001caa000000030a1f800000002d01108000005e8000123ec0093063000c0000268000000000001cab000000030a20800000002d0110800000228000123ec009318e040c0800268000000000001cac000000030a21800000002d0110800000388000123ec009347e000c1000268000000000001cad000000030a22800000002d0110800000678000123ec00938c4000c1800268000000000001cae000000030a23800000002d01108000005f8000123ec0093cf1000c2000268000000000001caf000000030a24800000002d0110800000278000123ec00940f1040c2800268000000000001cb0000000030a25800000002d0110800000138000123ec0094324000c3000268000000000001cb1000000030a26800000002d0110800000378000123ec0094463000c3800268000000000001cb2000000030a27800000002d0110800000688000123ec00945a0000c4000268000000000001cb3000000030a28800000002d0110800000648000123ec00945a1000c4800268000000000001cb4000000030a29800000002d01108000003c8000123ec0094605000c5000268000000000001cb5000000030a2a800000002d0110800000648000123ec00958a8000c5800268000000000001cb6000000030a2b800000002d0110800000048000123ec0095f13000c60c5778000000000001cb7000000030a2c800000002d0110800000278000123ec00960f600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007039ef395738bf3827378f36f7365f35c7352f349733ff336732cf3237319f3107306f2fd72f3f2ea72e0f2d772cdf2c472baf2b172a7f29e7294f28b7281f278726ef265725bf2527248f23f7235f22c7222f219720ff20671fcf1f371e9f1e071d6f1cd71c3f1ba71b0f1a7719df194718af1817177f16e7164f15b7151f148713ef135712bf1227118f10f7105f0fc70f2f0e970dff0d670ccf0c370b9f0b070a6f09d7093f08a7080f077706df064705af0517047f03e7034f02b7021f018700ef0063aa6b9b840de50035; asc ~ T 8 8 8 5E c; -align: middle;} infimum supremum & - - > D & . - 4 > & / - K > ( & 0 - $ > 0 & 1 - ^ > 8 & 2 - / > * @ & 3 - ; > H & 4 - d > P & 5 - K > X & 6 - e > d ` & 7 - / > h & 8 - K > p & 9 - g > 0 x & : - / > 1 & ; - K > 1 & < - E > 7\ & = - E > ;O & > - > B & ? - > C & @ - . > X & A - 6 > & B - e > & & C - b > " & D - / > !( & E - d > ! & F - > " & G - g > % & H - f > % & I - 7 > %] & J - C > () & K - > :* & L - h > ; & M - ' > ? & N - 8 > ? & O - " > B* ( & P - > D 0 & Q - > E 8 & R - C > I @ & S - ` > K* H & T - ` > K P & U - > MH X & V - C > a ` & W - E > n h & X - d > o p & Y - e > t x & Z - > u & [ - E > & \ - C > & ] - K > h & ^ - ' > & _ - > & ` - > & a - ^ > & b - " > & c - 4 > { & d - > & e - > > & f - ^ > h & g - > & h - ; > & i - K > & j - 4 > & k - 4 > & l - E > z & m - > & n - 4 > & o - > ( & p - > 0 & q - 4 > . 8 & r - > @ & s - / > ) H & t - > - P & u - d > 1G X & v - > 8 ` & w - > ST h & x - ; > T p & y - < > Uc x & z - > WI & { - 8 > [? & | - 8 > [ & } - 8 > [ & ~ - ' > w & - f > z & - 4 > w & - d > / & - b > G & - e > & - > S & - > % & - E > & - E > & - K > & - > , & - E > z & - E > y & - ^ > > & - > Y# & - 6 > \Z & - e > _ ( & - / > aM 0 & - > i 8 & - > j @ & - g > k H & - ^ > P & - > X & - 7 > | ` & - f > h & - b > c p & - h > = x & - d > e & - > t & - C > & - > E & - ; > & - d > M & - ' > & - b > & - b > & - > & - ^ > ) & - > & - > & - > & - 4 > & - > / & - 8 > | & - > D & ! - K > & " - d > 5 & # - h > & $ - ' > Q ( & % - d > f 0 & & - > g 8 & ' - E > @ & ( - b > z H & ) - > P & * - b > P X & + - > ` & , - b > h & - - > p & . - " > !w x & / - > # & 0 - > $9 & 1 - h > % & 2 - b > *6 & 3 - 7 > + & 4 - d > . & 5 - > E( & 6 - d > I & 7 - > N & 8 - d > O & 9 - > P & : - E > U & ; - 8 > lx & < - d > p & = - > r & > - > 5 & ? - E > & @ - b > c & A - ' > & B - K > & C - ^ > : & D - 4 > ( & E - / > 0 & F - > 8 & G - ^ > @ & H - ^ > H & I - ^ > , P & J - K > P X & K - 6 > ` & L - e > h & M - > p & N - b > ? x & O - 7 > G & P - > & Q - d > & R - > > & S - ^ > & T - g > & U - 8 > & V - h > & W - > & X - b > & Y - > & Z - ' > & [ - K > & \ - ^ > & ] - ^ > T & ^ - h > [ & _ - K > & ` - > & a - > X & b - ; > 5 & c - > A & d - ^ > # ( & e - > 0 & f - h > L 8 & g - 4 > N @ & h - / > H & i - / > P & j - ; > X & k - 4 > ` & l - ^ > # h & m - ^ > p & n - ^ > l x & o - > & p - > & q - g > "u & r - > F & s - 4 > Z & t - 4 > _ & u - 4 > a* & v - > b & w - ^ > f & x - L > k & y - > k & z - K > m, & { - > p= & | - > qv & } - > 0 & ~ - > e & - d > & - C > & - ^ > & - > & - > ! & - > ( & - ^ > 0 & - > 3 8 & - b > @ & - K > H & - ^ > P & - ^ > O X & - e > ` & - > ^ h & - 4 > 9 p & - 4 > x & - K > } & - 4 > & - > & - > v & - ' > & - > 0 & - ^ > & ! - ' > & " - > & # - > 7 & $ - ' > & % - < > n & & - > & ' - f > & ( - ^ > & & ) - 6 > '' & * - > 1 & + - 4 > & , - 4 > & - - / > & . - " > & / - e > ( & 0 - b > 0 & 1 - f > t 8 & 2 - K > @ & 3 - / > H & 4 - 7 > P & 5 - > k X & 6 - 8 > o ` & 7 - C > ! h & 8 - E > p & 9 - ^ > x & : - > & ; - d > & < - 4 > & = - > P & > - ' > + & ? - > & @ - ^ > I & A - h > & B - b > & C - > & D - L > & E - h > K & F - ; > & G - > & H - . > H & I - ` > & J - ` > & K - > h & L - ^ > & M - > & N - 6 > & O - K > - ( & P - < > 0 & Q - ; > ( 8 & R - 4 > 3 @ & S - > H & T - ^ > P & U - 4 > ") X & V - 4 > ) ` & W - > DB h & X - 4 > J p & Y - 4 > N x & Z - > O9 & [ - b > g & \ - / > h1 & ] - > h7 & ^ - 4 > hv & _ - b > iD & ` - / > i & a - d > lT & b - > n & c - ^ > pZ & d - f > p^ & e - 4 > q & f - / > s & g - h > s & h - K > u[ & i - 8 > & j - d > & k - > 8 & l - > & m - > & & n - ' > 6 & o - g > ( & p - ^ > 0 & q - > 8 & r - > @ & s - e > _ H & t - ^ > P & u - > X & v - d > ` & w - ' > h & x - h > p & y - e > x & z - ; > & { - d > & | - > & } - b > ] & ~ - E > & - ^ > & - > & - ^ > & - h > & - 4 > *M & - > +k & - > -I & - > - & - > . & - ^ > . & - 4 > = & - h > SX & - ^ > }t & - > n & - e > l & - E > & - 6 > : ( & - / > k 0 & - h > 8 & - f > @ & - 4 > H & - > P & - b > X & - d > ] ` & - b > 4 h & - 7 > 3 p & - K > m x & - f > & - b > & - g > & - 8 > x & - / > T & - > & - > & - d > + & - > & - > & - C > & - > U & - ^ > & - ^ > & - E > $ & - > & - ^ > 0c & - " > 1 & ! - 8 > 4~ & " - g > 8 & # - _ > < & $ - ' > @ ( & % - > C$ 0 & & - 7 > Dc 8 & ' - h > E @ & ( - d > E H & ) - < > F P & * - d > X X & + - > _ ` w , - ' > ` p9 9W8 8'7 6 6_5 5/4 3 3g2 271 1 0o/ /?. . -w, ,G+ + * ) )O( ( ' & &W% %'$ # #_" "/! g 7 o ? w G O W ' _ / g 7 o ? w G O c k 5;InnoDB: End of page dump 070514 15:01:53 InnoDB: Page checksum 2124914772, prior-to-4.0.14-form checksum 2859178884 InnoDB: stored checksum 2124914772, prior-to-4.0.14-form stored checksum 2859178884 InnoDB: Page lsn 0 233111605, low 4 bytes of lsn at page end 233111605 InnoDB: Page number (if stored to page already) 14472, InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0 InnoDB: Page may be an index page where index id is 0 176 InnoDB: (index PRIMARY of table adflow_v2/rmkMemberLog) InnoDB: rec address 0xb525e5f7, first buffer frame 0xb4c2c000 InnoDB: buffer pool high end 0xb542c000, buf block fix count 0 InnoDB: Index corruption: rec offs 9719 next offs 0, page no 14472, InnoDB: index `PRIMARY` of table `adflow_v2/insertionOrderApprovalStatus`. Run CHECK TABLE. You may need to InnoDB: restore from a backup, or dump + drop + reimport the table. InnoDB: We detected index corruption in an InnoDB type table. InnoDB: You have to dump + drop + reimport the table or, in InnoDB: a case of widespread corruption, dump all InnoDB InnoDB: tables and recreate the whole InnoDB tablespace. InnoDB: If the mysqld server crashes after the startup or when InnoDB: you dump the tables, look at InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html for help. 070514 15:01:53 [ERROR] Got error 126 when reading table './adflow_v2/insertionOrderApprovalStatus' InnoDB: Error: trying to access page number 101399424 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 15:09:15InnoDB: Assertion failure in thread 2539719600 in file fil0fil.c line 3959 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. 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=9 max_connections=100 threads_connected=9 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8f6d638 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=0x9760e9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 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 0x8f95e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070514 15:09:15 mysqld restarted 070514 15:09:15 [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=adflow-bin' to avoid this problem. 070514 15:09:15 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... 070514 15:09:15 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288897338. InnoDB: Doing recovery: scanned up to log sequence number 0 288897338 InnoDB: Last MySQL binlog file position 0 3998, file name ./adflow-bin.000083 070514 15:09:15 InnoDB: Started; log sequence number 0 288897338 070514 15:09:15 [Note] Recovering after a crash using adflow-bin 070514 15:09:15 [Note] Starting crash recovery... 070514 15:09:15 [Note] Crash recovery finished. 070514 15:09:16 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 148650880 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 15:31:20InnoDB: Assertion failure in thread 2539518896 in file fil0fil.c line 3959 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. 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=10 max_connections=100 threads_connected=9 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa44be88 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=0x975dd9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x3a3de8 0x95793a 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 0xa457330 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070514 15:31:20 mysqld restarted 070514 15:31:20 [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=adflow-bin' to avoid this problem. 070514 15:31:20 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... 070514 15:31:20 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288897348. InnoDB: Doing recovery: scanned up to log sequence number 0 288897348 InnoDB: Last MySQL binlog file position 0 3998, file name ./adflow-bin.000083 070514 15:31:20 InnoDB: Started; log sequence number 0 288897348 070514 15:31:20 [Note] Recovering after a crash using adflow-bin 070514 15:31:20 [Note] Starting crash recovery... 070514 15:31:20 [Note] Crash recovery finished. 070514 15:31:20 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 148650880 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 15:31:25InnoDB: Assertion failure in thread 2539719600 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9043638 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=0x9760e9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 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 0x906be68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070514 15:31:25 mysqld restarted 070514 15:31:25 [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=adflow-bin' to avoid this problem. 070514 15:31:25 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... 070514 15:31:25 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288897348. InnoDB: Doing recovery: scanned up to log sequence number 0 288897358 InnoDB: Last MySQL binlog file position 0 3998, file name ./adflow-bin.000083 070514 15:31:25 InnoDB: Started; log sequence number 0 288897358 070514 15:31:25 [Note] Recovering after a crash using adflow-bin 070514 15:31:25 [Note] Starting crash recovery... 070514 15:31:25 [Note] Crash recovery finished. 070514 15:31:25 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 148650880 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 15:31:28InnoDB: Assertion failure in thread 2539707312 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9213638 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=0x9760b9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x2e4de8 0x3cc93a 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 0x923be68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070514 15:31:28 mysqld restarted 070514 15:31:28 [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=adflow-bin' to avoid this problem. 070514 15:31:28 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... 070514 15:31:28 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288897368. InnoDB: Doing recovery: scanned up to log sequence number 0 288897368 InnoDB: Last MySQL binlog file position 0 3998, file name ./adflow-bin.000083 070514 15:31:28 InnoDB: Started; log sequence number 0 288897368 070514 15:31:28 [Note] Recovering after a crash using adflow-bin 070514 15:31:28 [Note] Starting crash recovery... 070514 15:31:28 [Note] Crash recovery finished. 070514 15:31:29 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 148650880 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 15:31:33InnoDB: Assertion failure in thread 2539711408 in file fil0fil.c line 3959 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. 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=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9c97638 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=0x9760c9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x115de8 0xdd793a 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 0x9cbfe68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070514 15:31:33 mysqld restarted 070514 15:31:33 [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=adflow-bin' to avoid this problem. 070514 15:31:33 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... 070514 15:31:33 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288897368. InnoDB: Doing recovery: scanned up to log sequence number 0 288897378 InnoDB: Last MySQL binlog file position 0 3998, file name ./adflow-bin.000083 070514 15:31:34 InnoDB: Started; log sequence number 0 288897378 070514 15:31:34 [Note] Recovering after a crash using adflow-bin 070514 15:31:34 [Note] Starting crash recovery... 070514 15:31:34 [Note] Crash recovery finished. 070514 15:31:34 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 148650880 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 15:31:41InnoDB: Assertion failure in thread 2539674544 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x95af638 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=0x976039dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x59ade8 0xe9d93a 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 0x95d7e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070514 15:31:41 mysqld restarted 070514 15:31:41 [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=adflow-bin' to avoid this problem. 070514 15:31:41 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... 070514 15:31:41 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288897378. InnoDB: Doing recovery: scanned up to log sequence number 0 288897388 InnoDB: Last MySQL binlog file position 0 3998, file name ./adflow-bin.000083 070514 15:31:41 InnoDB: Started; log sequence number 0 288897388 070514 15:31:41 [Note] Recovering after a crash using adflow-bin 070514 15:31:41 [Note] Starting crash recovery... 070514 15:31:41 [Note] Crash recovery finished. 070514 15:31:42 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 148650880 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 15:31:54InnoDB: Assertion failure in thread 2539514800 in file fil0fil.c line 3959 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. 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=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9cb4e88 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=0x975dc9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xa7fde8 0x2a893a 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 0x9cd8310 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta 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. Number of processes running now: 0 070514 15:31:54 mysqld restarted 070514 15:31:54 [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=adflow-bin' to avoid this problem. 070514 15:31:54 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... 070514 15:31:54 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288897398. InnoDB: Doing recovery: scanned up to log sequence number 0 288897398 InnoDB: Last MySQL binlog file position 0 3998, file name ./adflow-bin.000083 070514 15:31:54 InnoDB: Started; log sequence number 0 288897398 070514 15:31:54 [Note] Recovering after a crash using adflow-bin 070514 15:31:54 [Note] Starting crash recovery... 070514 15:31:54 [Note] Crash recovery finished. 070514 15:31:54 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 148650880 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 15:32:18InnoDB: Assertion failure in thread 2539727792 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9cf2638 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=0x976109dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xd1fde8 0xcb693a 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 0x9d1ae68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070514 15:32:18 mysqld restarted 070514 15:32:18 [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=adflow-bin' to avoid this problem. 070514 15:32:18 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... 070514 15:32:18 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288897408. InnoDB: Doing recovery: scanned up to log sequence number 0 288897408 InnoDB: Last MySQL binlog file position 0 3998, file name ./adflow-bin.000083 070514 15:32:18 InnoDB: Started; log sequence number 0 288897408 070514 15:32:18 [Note] Recovering after a crash using adflow-bin 070514 15:32:18 [Note] Starting crash recovery... 070514 15:32:18 [Note] Crash recovery finished. 070514 15:32:18 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 101399424 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 15:34:31InnoDB: Assertion failure in thread 2539723696 in file fil0fil.c line 3959 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. 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=2 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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa8e8638 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=0x9760f9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 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 0xa910e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070514 15:34:31 mysqld restarted 070514 15:34:31 [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=adflow-bin' to avoid this problem. 070514 15:34:31 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... 070514 15:34:31 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288898152. InnoDB: Doing recovery: scanned up to log sequence number 0 288898152 InnoDB: Last MySQL binlog file position 0 778, file name ./adflow-bin.000091 070514 15:34:31 InnoDB: Started; log sequence number 0 288898152 070514 15:34:31 [Note] Recovering after a crash using adflow-bin 070514 15:34:31 [Note] Starting crash recovery... 070514 15:34:31 [Note] Crash recovery finished. 070514 15:34:31 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 58407808 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 15:59:41InnoDB: Assertion failure in thread 2538134448 in file fil0fil.c line 3959 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. 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=11 max_connections=100 threads_connected=10 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9850a98 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=0x9748b9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xb2cde8 0x20f93a 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 0x985c358 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=13 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 070514 15:59:41 mysqld restarted 070514 15:59:41 [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=adflow-bin' to avoid this problem. 070514 15:59:41 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... 070514 15:59:41 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288950121. InnoDB: Doing recovery: scanned up to log sequence number 0 288950121 InnoDB: Last MySQL binlog file position 0 34122, file name ./adflow-bin.000092 070514 15:59:41 InnoDB: Started; log sequence number 0 288950121 070514 15:59:41 [Note] Recovering after a crash using adflow-bin 070514 15:59:41 [Note] Starting crash recovery... 070514 15:59:41 [Note] Crash recovery finished. 070514 15:59:41 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 58407808 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 16:00:05InnoDB: Assertion failure in thread 2539715504 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa5f6638 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=0x9760d9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x5a6de8 0x21a93a 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 0xa61ee68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070514 16:00:05 mysqld restarted 070514 16:00: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=adflow-bin' to avoid this problem. 070514 16:00:05 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... 070514 16:00:05 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288950160. InnoDB: Doing recovery: scanned up to log sequence number 0 288950170 InnoDB: Last MySQL binlog file position 0 34122, file name ./adflow-bin.000092 070514 16:00:05 InnoDB: Started; log sequence number 0 288950170 070514 16:00:05 [Note] Recovering after a crash using adflow-bin 070514 16:00:05 [Note] Starting crash recovery... 070514 16:00:05 [Note] Crash recovery finished. 070514 16:00:06 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 167721856 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 16:05:10InnoDB: Assertion failure in thread 2539711408 in file fil0fil.c line 3959 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. 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=3 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x985c638 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=0x9760c9fc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x68fde8 0x3ee93a 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 0x9884e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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 070514 16:05:10 mysqld restarted 070514 16:05:10 [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=adflow-bin' to avoid this problem. 070514 16:05:10 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... 070514 16:05:10 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288955273. InnoDB: Doing recovery: scanned up to log sequence number 0 288955273 InnoDB: Last MySQL binlog file position 0 2371, file name ./adflow-bin.000094 070514 16:05:10 InnoDB: Started; log sequence number 0 288955273 070514 16:05:10 [Note] Recovering after a crash using adflow-bin 070514 16:05:10 [Note] Starting crash recovery... 070514 16:05:10 [Note] Crash recovery finished. 070514 16:05:10 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 167721856 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 070514 16:05:16InnoDB: Assertion failure in thread 2539740080 in file fil0fil.c line 3959 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. 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=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 = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8ccc638 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=0x976139dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xd86de8 0x36793a 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 0x8cf4e68 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateTime , campaign.name , ioFlag , saleCode, overFlag , campaign.rmkMember_no , campaign.memo , campaign.advertiserBrand_id , campaign.agency_id , campaign.agencyMember_id , campaign.registDate , campaign.campaign_id as campaignId , updateRmkMember_no , campaign.startDate, advertiser.advertiser_id as advertiserId,company.name as advertiserName,advertiserBrand.name as advertiserBrandName, agencyCompany.name as agencyName, campaign_insertionOrder.insertionOrder_id as insertionOrderId, approvalStatus.name as approvalStatusName, campaign.rmkTeam_id, rmkTeam.name AS rmkTeamName, RMKcontact.name AS rmkMemberName , campaign.campaign_origin_id as campaignOriginId, campaign.campaignCopyReasonCode, campaign.campaignCopyReason FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOrderApprovalStatus USING ( insertionOrder_id ) LEFT JOIN approvalStatus USING ( approvalSta thd->thread_id=1 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.