Number of processes running now: 0 070514 16:05:17 mysqld restarted 070514 16:05:17 [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:17 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070514 16:05:17 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288955273. InnoDB: Doing recovery: scanned up to log sequence number 0 288955283 InnoDB: Last MySQL binlog file position 0 2371, file name ./adflow-bin.000094 070514 16:05:17 InnoDB: Started; log sequence number 0 288955283 070514 16:05:17 [Note] Recovering after a crash using adflow-bin 070514 16:05:17 [Note] Starting crash recovery... 070514 16:05:17 [Note] Crash recovery finished. 070514 16:05:17 [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:25InnoDB: 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=0xa38c638 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 0x567de8 0x2df93a 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 0xa3b4e68 = 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:25 mysqld restarted 070514 16:05: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 16:05: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 16:05:25 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288955283. InnoDB: Doing recovery: scanned up to log sequence number 0 288955293 InnoDB: Last MySQL binlog file position 0 2371, file name ./adflow-bin.000094 070514 16:05:25 InnoDB: Started; log sequence number 0 288955293 070514 16:05:25 [Note] Recovering after a crash using adflow-bin 070514 16:05:25 [Note] Starting crash recovery... 070514 16:05:25 [Note] Crash recovery finished. 070514 16:05: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 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:50InnoDB: 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=0x9668638 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... InnoDB: Thread 3010300848 stopped in file os0sync.c line 501 thd->query at 0x9690e68 = 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:50 mysqld restarted 070514 16:05: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. 070514 16:05: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... 070514 16:05:51 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288955654. InnoDB: Doing recovery: scanned up to log sequence number 0 288955654 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000097 070514 16:05:51 InnoDB: Started; log sequence number 0 288955654 070514 16:05:51 [Note] Recovering after a crash using adflow-bin 070514 16:05:51 [Note] Starting crash recovery... 070514 16:05:51 [Note] Crash recovery finished. 070514 16:05:51 [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 31931264 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:11: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=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=0xa43b638 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 0x8c1de8 0x2bb93a 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 3010288560 stopped in file ut0mem.c line 230 thd->query at 0xa463e68 = 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. InnoDB: Thread 2953059248 stopped in file ../include/sync0sync.ic line 111 Number of processes running now: 0 070514 16:11:06 mysqld restarted 070514 16:11: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. 070514 16:11: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... 070514 16:11:06 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288956473. InnoDB: Doing recovery: scanned up to log sequence number 0 288956473 InnoDB: Last MySQL binlog file position 0 646, file name ./adflow-bin.000098 070514 16:11:06 InnoDB: Started; log sequence number 0 288956473 070514 16:11:06 [Note] Recovering after a crash using adflow-bin 070514 16:11:06 [Note] Starting crash recovery... 070514 16:11:06 [Note] Crash recovery finished. 070514 16:11: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 104348544 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:20:15InnoDB: Assertion failure in thread 2539531184 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=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=0x8bdc7a8 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=0x975e09dc, 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 0xedbde8 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 0x8bef758 = 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 16:20:15 mysqld restarted 070514 16:20: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 16:20: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 16:20:15 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288957277. InnoDB: Doing recovery: scanned up to log sequence number 0 288957277 InnoDB: Last MySQL binlog file position 0 643, file name ./adflow-bin.000099 070514 16:20:15 InnoDB: Started; log sequence number 0 288957277 070514 16:20:15 [Note] Recovering after a crash using adflow-bin 070514 16:20:15 [Note] Starting crash recovery... 070514 16:20:15 [Note] Crash recovery finished. 070514 16:20: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 104348544 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:20:25InnoDB: 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=0xa85e638 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=0x976129dc, 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 0xb7dde8 0xeb293a 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 0xa886e68 = 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:20:25 mysqld restarted 070514 16:20: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 16:20: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 16:20:26 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288957277. InnoDB: Doing recovery: scanned up to log sequence number 0 288957287 InnoDB: Last MySQL binlog file position 0 643, file name ./adflow-bin.000099 070514 16:20:26 InnoDB: Started; log sequence number 0 288957287 070514 16:20:26 [Note] Recovering after a crash using adflow-bin 070514 16:20:26 [Note] Starting crash recovery... 070514 16:20:26 [Note] Crash recovery finished. 070514 16:20:26 [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 104348544 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:20:34InnoDB: 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=0xa870638 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 0x115de8 0x2ef93a 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 0xa898e68 = 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:20:34 mysqld restarted 070514 16:20: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. 070514 16:20: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... 070514 16:20:34 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288957287. InnoDB: Doing recovery: scanned up to log sequence number 0 288957297 InnoDB: Last MySQL binlog file position 0 643, file name ./adflow-bin.000099 070514 16:20:35 InnoDB: Started; log sequence number 0 288957297 070514 16:20:35 [Note] Recovering after a crash using adflow-bin 070514 16:20:35 [Note] Starting crash recovery... 070514 16:20:35 [Note] Crash recovery finished. 070514 16:20: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 104348544 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:20:45InnoDB: 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=0x9ff8638 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 0x1d7de8 0x2bf93a 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 0xa020e68 = 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:20:45 mysqld restarted 070514 16:20: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. 070514 16:20: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... 070514 16:20:45 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288957297. InnoDB: Doing recovery: scanned up to log sequence number 0 288957307 InnoDB: Last MySQL binlog file position 0 643, file name ./adflow-bin.000099 070514 16:20:45 InnoDB: Started; log sequence number 0 288957307 070514 16:20:45 [Note] Recovering after a crash using adflow-bin 070514 16:20:45 [Note] Starting crash recovery... 070514 16:20:45 [Note] Crash recovery finished. 070514 16:20: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 104348544 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:21:07InnoDB: 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=0x8d90638 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 0xef6de8 0x4eb93a 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 0x8db8e68 = 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:21:07 mysqld restarted 070514 16:21: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. 070514 16:21: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... 070514 16:21:07 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 288957307. InnoDB: Doing recovery: scanned up to log sequence number 0 288957317 InnoDB: Last MySQL binlog file position 0 643, file name ./adflow-bin.000099 070514 16:21:07 InnoDB: Started; log sequence number 0 288957317 070514 16:21:07 [Note] Recovering after a crash using adflow-bin 070514 16:21:07 [Note] Starting crash recovery... 070514 16:21:07 [Note] Crash recovery finished. 070514 16:21: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 181091200 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. 070515 14:01:01InnoDB: Assertion failure in thread 2485005232 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=62 max_connections=100 threads_connected=54 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=0x9516ba40 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=0x941e09fc, 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 0x604de8 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 0x8e35ae8 = SELECT campaign.endDate , proposalDetail_id , advertiserBrandMember_id , updateInnoDB: Thread 2963553200 stopped in file ../include/sync0sync.ic line 111 Time , 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=650 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 070515 14:01:01 mysqld restarted 070515 14:01: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. 070515 14:01: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... 070515 14:01:01 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 290522813. InnoDB: Doing recovery: scanned up to log sequence number 0 290523583 070515 14:01:01 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 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 1559229, file name ./adflow-bin.000104 070515 14:01:02 InnoDB: Started; log sequence number 0 290523583 070515 14:01:02 [Note] Recovering after a crash using adflow-bin 070515 14:01:02 [Note] Starting crash recovery... 070515 14:01:02 [Note] Crash recovery finished. 070515 14:01: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 93141888 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. 070515 14:24:49InnoDB: 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=23 max_connections=100 threads_connected=22 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=0x99e1950 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 0xec1de8 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 0x99ebfe0 = 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 070515 14:24:49 mysqld restarted 070515 14:24: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. 070515 14:24: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... 070515 14:24:49 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 290670299. InnoDB: Doing recovery: scanned up to log sequence number 0 290670299 InnoDB: Last MySQL binlog file position 0 147323, file name ./adflow-bin.000105 070515 14:24:49 InnoDB: Started; log sequence number 0 290670299 070515 14:24:49 [Note] Recovering after a crash using adflow-bin 070515 14:24:49 [Note] Starting crash recovery... 070515 14:24:49 [Note] Crash recovery finished. 070515 14:24: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 181353344 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. 070515 14:24:54InnoDB: 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=0x96bf638 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 0xd75de8 0x9c493a 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 0x96e7e68 = 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 070515 14:24:54 mysqld restarted 070515 14:24: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. 070515 14:24: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... 070515 14:24:55 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 290670299. InnoDB: Doing recovery: scanned up to log sequence number 0 290670309 InnoDB: Last MySQL binlog file position 0 147323, file name ./adflow-bin.000105 070515 14:24:55 InnoDB: Started; log sequence number 0 290670309 070515 14:24:55 [Note] Recovering after a crash using adflow-bin 070515 14:24:55 [Note] Starting crash recovery... 070515 14:24:55 [Note] Crash recovery finished. 070515 14:24: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 172112768 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. 070515 14:25:15InnoDB: Assertion failure in thread 2539535280 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=0xa34fe88 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=0x975e19dc, 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 0xce1de8 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 0xa35b330 = 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 070515 14:25:15 mysqld restarted 070515 14:25: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. 070515 14:25: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... 070515 14:25:15 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 290670737. InnoDB: Doing recovery: scanned up to log sequence number 0 290670737 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000107 070515 14:25:15 InnoDB: Started; log sequence number 0 290670737 070515 14:25:15 [Note] Recovering after a crash using adflow-bin 070515 14:25:15 [Note] Starting crash recovery... 070515 14:25:15 [Note] Crash recovery finished. 070515 14:25: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 181353344 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. 070515 14:26:09InnoDB: 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=0x9c5e638 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 0x9c86e68 = 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 070515 14:26:09 mysqld restarted 070515 14:26: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. 070515 14:26: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... 070515 14:26:09 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 290670737. InnoDB: Doing recovery: scanned up to log sequence number 0 290670747 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000107 070515 14:26:09 InnoDB: Started; log sequence number 0 290670747 070515 14:26:09 [Note] Recovering after a crash using adflow-bin 070515 14:26:09 [Note] Starting crash recovery... 070515 14:26:09 [Note] Crash recovery finished. 070515 14:26: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 181353344 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. 070515 14:27:06InnoDB: Assertion failure in thread 2539666352 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=0x91a4638 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=0x976019dc, 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 0xc3dde8 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 3010288560 stopped in file os0sync.c line 501 thd->query at 0x91cce68 = 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 070515 14:27:06 mysqld restarted 070515 14:27: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. 070515 14:27: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... 070515 14:27:07 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 290670757. InnoDB: Doing recovery: scanned up to log sequence number 0 290670757 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000107 070515 14:27:07 InnoDB: Started; log sequence number 0 290670757 070515 14:27:07 [Note] Recovering after a crash using adflow-bin 070515 14:27:07 [Note] Starting crash recovery... 070515 14:27:07 [Note] Crash recovery finished. 070515 14:27: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 172112768 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. 070515 14:27:18InnoDB: 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=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 InnoDB: Thread 3010292656 stopped in file os0sync.c line 501 Hope that's ok; if not, decrease some variables in the equation. thd=0x8c8f638 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 0x42cde8 0x7ac93a 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 0x8cb7e68 = 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 070515 14:27:18 mysqld restarted 070515 14:27: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. 070515 14:27: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... 070515 14:27:18 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 290670757. InnoDB: Doing recovery: scanned up to log sequence number 0 290670767 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000107 070515 14:27:18 InnoDB: Started; log sequence number 0 290670767 070515 14:27:18 [Note] Recovering after a crash using adflow-bin 070515 14:27:18 [Note] Starting crash recovery... 070515 14:27:18 [Note] Crash recovery finished. 070515 14:27: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 95239040 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. 070515 18:09:48InnoDB: 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=57 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=0x9108638 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 0x2fede8 0x3e693a 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 0x9131280 = 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 070515 18:09:48 mysqld restarted 070515 18:09:48 [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. 070515 18:09:48 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... 070515 18:09:48 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 291161828. InnoDB: Doing recovery: scanned up to log sequence number 0 291161828 InnoDB: Last MySQL binlog file position 0 450027, file name ./adflow-bin.000111 070515 18:09:48 InnoDB: Started; log sequence number 0 291161828 070515 18:09:48 [Note] Recovering after a crash using adflow-bin 070515 18:09:48 [Note] Starting crash recovery... 070515 18:09:48 [Note] Crash recovery finished. 070515 18:09: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) 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=51 max_connections=100 threads_connected=42 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=0x9829808 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=0x96fc80dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x82b5346 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xbe3de8 0xaee93a 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 0x95c1110 = 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=622 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 070516 11:29:31 mysqld restarted 070516 11: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. 070516 11: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... 070516 11:29:31 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 292650180. InnoDB: Doing recovery: scanned up to log sequence number 0 292650180 InnoDB: Last MySQL binlog file position 0 1472017, file name ./adflow-bin.000112 070516 11:29:31 InnoDB: Started; log sequence number 0 292650180 070516 11:29:31 [Note] Recovering after a crash using adflow-bin 070516 11:29:31 [Note] Starting crash recovery... 070516 11:29:31 [Note] Crash recovery finished. 070516 11: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 22362496 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. 070516 13:23:59InnoDB: 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=14 max_connections=100 threads_connected=13 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=0x9fef3c0 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=0x973fd9fc, 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 0xb7cde8 0x3df93a 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 0x9fe24c0 = 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 070516 13:23:59 mysqld restarted 070516 13:23: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. 070516 13:24:00 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070516 13:24:00 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 293349366. InnoDB: Doing recovery: scanned up to log sequence number 0 293349366 InnoDB: Last MySQL binlog file position 0 709284, file name ./adflow-bin.000113 070516 13:24:00 InnoDB: Started; log sequence number 0 293349366 070516 13:24:00 [Note] Recovering after a crash using adflow-bin 070516 13:24:00 [Note] Starting crash recovery... 070516 13:24:00 [Note] Crash recovery finished. 070516 13:24: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 22362496 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. 070516 13:24:04InnoDB: 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=0xa74d638 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 0x6b8de8 0x28c93a 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 0xa775e68 = 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 070516 13:24:04 mysqld restarted 070516 13:24: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. 070516 13:24: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... 070516 13:24:04 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 293349366. InnoDB: Doing recovery: scanned up to log sequence number 0 293349392 InnoDB: Last MySQL binlog file position 0 709284, file name ./adflow-bin.000113 070516 13:24:04 InnoDB: Started; log sequence number 0 293349392 070516 13:24:04 [Note] Recovering after a crash using adflow-bin 070516 13:24:04 [Note] Starting crash recovery... 070516 13:24:04 [Note] Crash recovery finished. 070516 13:24: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 22362496 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. 070516 13:24:16InnoDB: 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=0xa640638 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=0x976109fc, 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 0x1e7de8 0x49393a 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 0xa668e68 = 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 070516 13:24:16 mysqld restarted 070516 13:24: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. 070516 13:24: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... 070516 13:24:16 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 293349392. InnoDB: Doing recovery: scanned up to log sequence number 0 293349402 InnoDB: Last MySQL binlog file position 0 709284, file name ./adflow-bin.000113 070516 13:24:16 InnoDB: Started; log sequence number 0 293349402 070516 13:24:16 [Note] Recovering after a crash using adflow-bin 070516 13:24:16 [Note] Starting crash recovery... 070516 13:24:16 [Note] Crash recovery finished. 070516 13:24: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 22362496 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. 070516 13:24:20InnoDB: 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=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=0xa392638 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 0xdc2de8 0x2f093a 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 0xa3bae68 = 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 070516 13:24:20 mysqld restarted 070516 13:24: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. 070516 13:24: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... 070516 13:24:21 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 293349402. InnoDB: Doing recovery: scanned up to log sequence number 0 293349879 070516 13:24:21 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 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.000116 070516 13:24:21 InnoDB: Started; log sequence number 0 293349879 070516 13:24:21 [Note] Recovering after a crash using adflow-bin 070516 13:24:21 [Note] Starting crash recovery... 070516 13:24:21 [Note] Crash recovery finished. 070516 13:24: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 15939968 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. 070516 13:24: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=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=0x96d3638 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 0x96fbe68 = 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 insertionOrderApprovalInnoDB: Thread 2953071536 stopped in file ../include/sync0sync.ic line 111 Status 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 070516 13:24:35 mysqld restarted 070516 13:24: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. 070516 13:24: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... 070516 13:24:36 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 293350372. InnoDB: Doing recovery: scanned up to log sequence number 0 293350372 InnoDB: Last MySQL binlog file position 0 271, file name ./adflow-bin.000117 070516 13:24:36 InnoDB: Started; log sequence number 0 293350372 070516 13:24:36 [Note] Recovering after a crash using adflow-bin 070516 13:24:36 [Note] Starting crash recovery... 070516 13:24:36 [Note] Crash recovery finished. 070516 13:24: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 22362496 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. 070516 13:24:40InnoDB: Assertion failure in thread 2538466224 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=0x93cf840 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=0x974dc9fc, 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 0x23b93a 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 0x93db3b0 = 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 070516 13:24:40 mysqld restarted 070516 13:24: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. 070516 13:24: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... 070516 13:24:40 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 293350372. InnoDB: Doing recovery: scanned up to log sequence number 0 293350382 InnoDB: Last MySQL binlog file position 0 271, file name ./adflow-bin.000117 070516 13:24:40 InnoDB: Started; log sequence number 0 293350382 070516 13:24:40 [Note] Recovering after a crash using adflow-bin 070516 13:24:40 [Note] Starting crash recovery... 070516 13:24:40 [Note] Crash recovery finished. 070516 13:24: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 22362496 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. 070516 13:24:45InnoDB: Assertion failure in thread 2538462128 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=0x9140840 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=0x974db9fc, 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 0x6b7de8 0xd6793a 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 0x914c3b0 = 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 070516 13:24:45 mysqld restarted 070516 13:24: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. 070516 13:24: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... 070516 13:24:46 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 293350382. InnoDB: Doing recovery: scanned up to log sequence number 0 293350392 InnoDB: Last MySQL binlog file position 0 271, file name ./adflow-bin.000117 070516 13:24:46 InnoDB: Started; log sequence number 0 293350392 070516 13:24:46 [Note] Recovering after a crash using adflow-bin 070516 13:24:46 [Note] Starting crash recovery... 070516 13:24:46 [Note] Crash recovery finished. 070516 13:24: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 22362496 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. 070516 13:24:50InnoDB: Assertion failure in thread 2537409456 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 2539711408 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=0x8c62e10 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=0x973da9fc, 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 0x371de8 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 0x8c666b0 = 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 070516 13:24:50 mysqld restarted 070516 13:24: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. 070516 13:24: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... 070516 13:24:50 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 293350382. InnoDB: Doing recovery: scanned up to log sequence number 0 293350418 InnoDB: Last MySQL binlog file position 0 271, file name ./adflow-bin.000117 070516 13:24:50 InnoDB: Started; log sequence number 0 293350418 070516 13:24:50 [Note] Recovering after a crash using adflow-bin 070516 13:24:50 [Note] Starting crash recovery... 070516 13:24:50 [Note] Crash recovery finished. 070516 13:24: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 22362496 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. 070516 13:24:54InnoDB: 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=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=0x8c50638 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 0x8c78e68 = 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 070516 13:24:54 mysqld restarted 070516 13:24: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. 070516 13:24: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... 070516 13:24:55 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 293350418. InnoDB: Doing recovery: scanned up to log sequence number 0 293352538 070516 13:24:55 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 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 617, file name ./adflow-bin.000121 070516 13:24:55 InnoDB: Started; log sequence number 0 293352538 070516 13:24:55 [Note] Recovering after a crash using adflow-bin 070516 13:24:55 [Note] Starting crash recovery... 070516 13:24:55 [Note] Crash recovery finished. 070516 13:24: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 22362496 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. 070516 13:24:59InnoDB: Assertion failure in thread 2539498416 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=0xa571c90 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=0x975d89fc, 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 0x115de8 0xb0893a 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 0xa57d788 = 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 070516 13:24:59 mysqld restarted 070516 13:24: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. 070516 13:24: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... 070516 13:24:59 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 293350418. InnoDB: Doing recovery: scanned up to log sequence number 0 293353031 070516 13:24:59 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 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.000122 070516 13:25:00 InnoDB: Started; log sequence number 0 293353031 070516 13:25:00 [Note] Recovering after a crash using adflow-bin 070516 13:25:00 [Note] Starting crash recovery... 070516 13:25:00 [Note] Crash recovery finished. 070516 13:25: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 22362496 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. 070516 13:26:42InnoDB: 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=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=0x9ff4e88 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 InnoDB: Thread 3010276272 stopped in file os0sync.c line 501 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xbd5de8 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 0xa018310 = 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 070516 13:26:42 mysqld restarted 070516 13:26: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. 070516 13:26: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... 070516 13:26:42 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 293353761. InnoDB: Doing recovery: scanned up to log sequence number 0 293353761 InnoDB: Last MySQL binlog file position 0 646, file name ./adflow-bin.000123 070516 13:26:42 InnoDB: Started; log sequence number 0 293353761 070516 13:26:42 [Note] Recovering after a crash using adflow-bin 070516 13:26:42 [Note] Starting crash recovery... 070516 13:26:42 [Note] Crash recovery finished. 070516 13:26:43 [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 22362496 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. 070516 13:26:48InnoDB: 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=0x9d24638 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 0xacbde8 0x1f093a 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 0x9d4ce68 = 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 070516 13:26:48 mysqld restarted 070516 13:26:48 [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. 070516 13:26:48 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... 070516 13:26:48 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 293353761. InnoDB: Doing recovery: scanned up to log sequence number 0 293353771 InnoDB: Last MySQL binlog file position 0 646, file name ./adflow-bin.000123 070516 13:26:48 InnoDB: Started; log sequence number 0 293353771 070516 13:26:48 [Note] Recovering after a crash using adflow-bin 070516 13:26:48 [Note] Starting crash recovery... 070516 13:26:48 [Note] Crash recovery finished. 070516 13:26: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 85473664 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. 070516 13:29:38InnoDB: Assertion failure in thread 2536504240 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=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=0x8d27b70 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=0x972fd9dc, 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 0xd81de8 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 2963561392 stopped in file sync0arr.c line 126 thd->query at 0x8d42780 = 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 070516 13:29:38 mysqld restarted 070516 13:29:38 [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. 070516 13:29:38 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... 070516 13:29:38 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 293597734. InnoDB: Doing recovery: scanned up to log sequence number 0 293597734 InnoDB: Last MySQL binlog file position 0 243283, file name ./adflow-bin.000125 070516 13:29:38 InnoDB: Started; log sequence number 0 293597734 070516 13:29:38 [Note] Recovering after a crash using adflow-bin 070516 13:29:38 [Note] Starting crash recovery... 070516 13:29:38 [Note] Crash recovery finished. 070516 13:29:39 [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) 070521 14:05:11 mysqld started 070521 14:05:13 [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. 070521 14:05: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... 070521 14:05:14 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 295164776. InnoDB: Doing recovery: scanned up to log sequence number 0 295164776 InnoDB: Last MySQL binlog file position 0 1410292, file name ./adflow-bin.000126 070521 14:05:14 InnoDB: Started; log sequence number 0 295164776 070521 14:05:14 [Note] Recovering after a crash using adflow-bin 070521 14:05:14 [Note] Starting crash recovery... 070521 14:05:14 [Note] Crash recovery finished. 070521 14:05: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 176241024 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. 070521 14:16:03InnoDB: Assertion failure in thread 2539469744 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=0x933e300 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=0x975d19fc, 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 0x1b2de8 0x29a93a 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 0x934db88 = 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=8 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 070521 14:16:03 mysqld restarted 070521 14:16: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. 070521 14:16: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... 070521 14:16:03 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 295165523. InnoDB: Doing recovery: scanned up to log sequence number 0 295165523 InnoDB: Last MySQL binlog file position 0 645, file name ./adflow-bin.000127 070521 14:16:03 InnoDB: Started; log sequence number 0 295165523 070521 14:16:03 [Note] Recovering after a crash using adflow-bin 070521 14:16:03 [Note] Starting crash recovery... 070521 14:16:03 [Note] Crash recovery finished. 070521 14:16: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 176241024 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. 070521 14:21:23InnoDB: 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=5 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=0x9669638 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 0x9691e68 = 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 070521 14:21:23 mysqld restarted 070521 14:21: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. 070521 14:21: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... 070521 14:21:23 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 295167483. InnoDB: Doing recovery: scanned up to log sequence number 0 295167483 InnoDB: Last MySQL binlog file position 0 2001, file name ./adflow-bin.000128 070521 14:21:23 InnoDB: Started; log sequence number 0 295167483 070521 14:21:23 [Note] Recovering after a crash using adflow-bin 070521 14:21:23 [Note] Starting crash recovery... 070521 14:21:23 [Note] Crash recovery finished. 070521 14:21: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) 070521 15:17:54 mysqld started 070521 15:17: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. 070521 15:17: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... 070521 15:17:57 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 295538542. InnoDB: Doing recovery: scanned up to log sequence number 0 295538542 InnoDB: Last MySQL binlog file position 0 294246, file name ./adflow-bin.000129 070521 15:17:57 InnoDB: Started; log sequence number 0 295538542 070521 15:17:57 [Note] Recovering after a crash using adflow-bin 070521 15:17:57 [Note] Starting crash recovery... 070521 15:17:57 [Note] Crash recovery finished. 070521 15:17: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) 070521 15:27:22 mysqld started 070521 15:27: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. 070521 15:27: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... 070521 15:27:24 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 295540484. InnoDB: Doing recovery: scanned up to log sequence number 0 295540484 InnoDB: Last MySQL binlog file position 0 1466, file name ./adflow-bin.000130 070521 15:27:25 InnoDB: Started; log sequence number 0 295540484 070521 15:27:25 [Note] Recovering after a crash using adflow-bin 070521 15:27:25 [Note] Starting crash recovery... 070521 15:27:25 [Note] Crash recovery finished. 070521 15:27: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) 070530 13:03:43 mysqld started 070530 13:03: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. 070530 13:03: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... 070530 13:03:46 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 303551679. InnoDB: Doing recovery: scanned up to log sequence number 0 303551679 InnoDB: Last MySQL binlog file position 0 7933165, file name ./adflow-bin.000131 070530 13:03:46 InnoDB: Started; log sequence number 0 303551679 070530 13:03:46 [Note] Recovering after a crash using adflow-bin 070530 13:03:46 [Note] Starting crash recovery... 070530 13:03:46 [Note] Crash recovery finished. 070530 13:03: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 186922880 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. 070530 13:06:27InnoDB: 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=0x94e4170 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 0xc3ade8 0x76093a 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 0x94f0390 = 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=7 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 070530 13:06:27 mysqld restarted 070530 13:06: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. 070530 13:06: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... 070530 13:06:27 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 303553003. InnoDB: Doing recovery: scanned up to log sequence number 0 303553003 InnoDB: Last MySQL binlog file position 0 717, file name ./adflow-bin.000132 070530 13:06:27 InnoDB: Started; log sequence number 0 303553003 070530 13:06:27 [Note] Recovering after a crash using adflow-bin 070530 13:06:27 [Note] Starting crash recovery... 070530 13:06:27 [Note] Crash recovery finished. 070530 13:06: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) 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=0xa6b90a0 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=0x976120dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x82b5346 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x691de8 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 0xa6c53e0 = 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 070530 13:06:31 mysqld restarted 070530 13:06: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. 070530 13:06: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... 070530 13:06:32 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 303553003. InnoDB: Doing recovery: scanned up to log sequence number 0 303553003 InnoDB: Last MySQL binlog file position 0 717, file name ./adflow-bin.000132 070530 13:06:32 InnoDB: Started; log sequence number 0 303553003 070530 13:06:32 [Note] Recovering after a crash using adflow-bin 070530 13:06:32 [Note] Starting crash recovery... 070530 13:06:32 [Note] Crash recovery finished. 070530 13:06:32 [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 186922880 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. 070531 7:44:12InnoDB: Assertion failure in thread 2529700784 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=62 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=0xab3fb40 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=0x96c809fc, 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 0x823de8 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 0x9740ef88 is invalid pointer thd->thread_id=563 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 070531 07:44:12 mysqld restarted 070531 7:44: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. 070531 7:44:12 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... 070531 7:44:12 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 304140674. InnoDB: Doing recovery: scanned up to log sequence number 0 304140674 InnoDB: Last MySQL binlog file position 0 588263, file name ./adflow-bin.000134 070531 7:44:12 InnoDB: Started; log sequence number 0 304140674 070531 7:44:12 [Note] Recovering after a crash using adflow-bin 070531 7:44:13 [Note] Starting crash recovery... 070531 7:44:13 [Note] Crash recovery finished. 070531 7:44: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 139212672 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. 070604 18:28:15InnoDB: Assertion failure in thread 2529856432 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=62 max_connections=100 threads_connected=54 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=0x968471f0 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=0x96ca69dc, 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 0x1fd93a 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 0x952ae10 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr thd->thread_id=3082 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 070604 18:28:15 mysqld restarted 070604 18:28: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. 070604 18:28: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... 070604 18:28:15 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 309524345. InnoDB: Doing recovery: scanned up to log sequence number 0 309524345 InnoDB: Last MySQL binlog file position 0 4252524, file name ./adflow-bin.000135 070604 18:28:15 InnoDB: Started; log sequence number 0 309524345 070604 18:28:15 [Note] Recovering after a crash using adflow-bin 070604 18:28:16 [Note] Starting crash recovery... 070604 18:28:16 [Note] Crash recovery finished. 070604 18:28: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 76232576 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. 070604 21:18:25InnoDB: 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=21 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=0xaa200a0 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 0x198de8 0x80493a 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 0xaa2c3e0 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070604 21:18:25 mysqld restarted 070604 21:18: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. 070604 21:18: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... 070604 21:18:25 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 309557567. InnoDB: Doing recovery: scanned up to log sequence number 0 309557567 InnoDB: Last MySQL binlog file position 0 16175, file name ./adflow-bin.000136 070604 21:18:25 InnoDB: Started; log sequence number 0 309557567 070604 21:18:25 [Note] Recovering after a crash using adflow-bin 070604 21:18:25 [Note] Starting crash recovery... 070604 21:18:25 [Note] Crash recovery finished. 070604 21:18: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 76232576 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. 070604 21:18:31InnoDB: Assertion failure in thread 2539686832 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=0x92280a0 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=0x976069dc, 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 0x465de8 0xd7a93a 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 3010309040 stopped in file ut0mem.c line 230 thd->query at 0x92343e0 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070604 21:18:31 mysqld restarted 070604 21:18: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. 070604 21:18: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... 070604 21:18:31 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 309557567. InnoDB: Doing recovery: scanned up to log sequence number 0 309557577 InnoDB: Last MySQL binlog file position 0 16175, file name ./adflow-bin.000136 070604 21:18:31 InnoDB: Started; log sequence number 0 309557577 070604 21:18:31 [Note] Recovering after a crash using adflow-bin 070604 21:18:31 [Note] Starting crash recovery... 070604 21:18:31 [Note] Crash recovery finished. 070604 21:18: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 141571968 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. 070605 8:21:12InnoDB: Assertion failure in thread 2539068336 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=14 max_connections=100 threads_connected=14 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=0x9cde1b0 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=0x9756f9dc, 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 0x9ce9658 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr thd->thread_id=265 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 070605 08:21:12 mysqld restarted 070605 8:21: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. 070605 8:21: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... 070605 8:21:13 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 309568798. InnoDB: Doing recovery: scanned up to log sequence number 0 309568798 InnoDB: Last MySQL binlog file position 0 9032, file name ./adflow-bin.000138 070605 8:21:13 InnoDB: Started; log sequence number 0 309568798 070605 8:21:13 [Note] Recovering after a crash using adflow-bin 070605 8:21:13 [Note] Starting crash recovery... 070605 8:21:13 [Note] Crash recovery finished. 070605 8:21: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 184956800 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. 070605 8:21:19InnoDB: 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=0xa0170a0 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 0xa0233e0 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070605 08:21:19 mysqld restarted 070605 8:21: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. 070605 8:21: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... 070605 8:21:19 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 309568798. InnoDB: Doing recovery: scanned up to log sequence number 0 309569226 070605 8:21:19 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 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 372, file name ./adflow-bin.000139 070605 8:21:19 InnoDB: Started; log sequence number 0 309569226 070605 8:21:19 [Note] Recovering after a crash using adflow-bin 070605 8:21:19 [Note] Starting crash recovery... 070605 8:21:19 [Note] Crash recovery finished. 070605 8:21: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 184956800 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. 070605 8:21:25InnoDB: 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=0x9565638 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 0xa25de8 0x7fa93a 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 0x958de68 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070605 08:21:26 mysqld restarted 070605 8:21: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. 070605 8:21: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... 070605 8:21:26 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 309568798. InnoDB: Doing recovery: scanned up to log sequence number 0 309569236 070605 8:21:26 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 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 372, file name ./adflow-bin.000139 070605 8:21:26 InnoDB: Started; log sequence number 0 309569236 070605 8:21:26 [Note] Recovering after a crash using adflow-bin 070605 8:21:26 [Note] Starting crash recovery... 070605 8:21:26 [Note] Crash recovery finished. 070605 8:21:26 [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 184956800 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. 070605 8:21:33InnoDB: 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=0x8ae80a0 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 0x2a1de8 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 0x8af43e0 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070605 08:21:33 mysqld restarted 070605 8:21: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. 070605 8:21: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... 070605 8:21:34 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 309569236. InnoDB: Doing recovery: scanned up to log sequence number 0 309569246 InnoDB: Last MySQL binlog file position 0 372, file name ./adflow-bin.000139 070605 8:21:34 InnoDB: Started; log sequence number 0 309569246 070605 8:21:34 [Note] Recovering after a crash using adflow-bin 070605 8:21:34 [Note] Starting crash recovery... 070605 8:21:34 [Note] Crash recovery finished. 070605 8:21: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 184956800 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. 070605 8:21:39InnoDB: 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=0xa2c50a0 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 0xa2d13e0 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070605 08:21:39 mysqld restarted 070605 8:21: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. 070605 8:21: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... 070605 8:21:40 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 309569246. InnoDB: Doing recovery: scanned up to log sequence number 0 309569256 InnoDB: Last MySQL binlog file position 0 372, file name ./adflow-bin.000139 070605 8:21:40 InnoDB: Started; log sequence number 0 309569256 070605 8:21:40 [Note] Recovering after a crash using adflow-bin 070605 8:21:40 [Note] Starting crash recovery... 070605 8:21:40 [Note] Crash recovery finished. 070605 8:21: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 184956800 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. 070605 8:22:00InnoDB: 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=0xa9280a0 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 0x4d4de8 0xcc493a 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 0xa9343e0 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070605 08:22:00 mysqld restarted 070605 8:22:00 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070605 8:22:00 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070605 8:22:00 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 309569684. InnoDB: Doing recovery: scanned up to log sequence number 0 309569684 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000143 070605 8:22:00 InnoDB: Started; log sequence number 0 309569684 070605 8:22:00 [Note] Recovering after a crash using adflow-bin 070605 8:22:00 [Note] Starting crash recovery... 070605 8:22:00 [Note] Crash recovery finished. 070605 8:22:01 [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 16660352 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. 070605 14:29:52InnoDB: Assertion failure in thread 2520153008 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=15 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=0xab90bc0 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=0x963659dc, 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 0x465de8 0x2ec93a 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 0xabb5638 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr thd->thread_id=174 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 070605 14:29:52 mysqld restarted 070605 14:29: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. 070605 14:29: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... 070605 14:29:53 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 310301294. InnoDB: Doing recovery: scanned up to log sequence number 0 310301294 InnoDB: Last MySQL binlog file position 0 710986, file name ./adflow-bin.000144 070605 14:29:53 InnoDB: Started; log sequence number 0 310301294 070605 14:29:53 [Note] Recovering after a crash using adflow-bin 070605 14:29:53 [Note] Starting crash recovery... 070605 14:29:53 [Note] Crash recovery finished. 070605 14:29:53 [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 136853376 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. 070605 15:02:35InnoDB: 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=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=0x9664c80 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 0xf8bde8 0xb6993a 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 0x966f310 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070605 15:02:35 mysqld restarted 070605 15:02: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. 070605 15:02: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... 070605 15:02:35 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 310306019. InnoDB: Doing recovery: scanned up to log sequence number 0 310306019 InnoDB: Last MySQL binlog file position 0 2403, file name ./adflow-bin.000145 070605 15:02:35 InnoDB: Started; log sequence number 0 310306019 070605 15:02:35 [Note] Recovering after a crash using adflow-bin 070605 15:02:35 [Note] Starting crash recovery... 070605 15:02:35 [Note] Crash recovery finished. 070605 15:02: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 184956800 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. 070605 15:25:53InnoDB: 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=31 max_connections=100 threads_connected=30 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=0x8f68c80 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 0xa5dde8 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 0x8f73310 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070605 15:25:53 mysqld restarted 070605 15:25: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. 070605 15:25: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... 070605 15:25:53 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 310592238. InnoDB: Doing recovery: scanned up to log sequence number 0 310592238 InnoDB: Last MySQL binlog file position 0 289139, file name ./adflow-bin.000146 070605 15:25:53 InnoDB: Started; log sequence number 0 310592238 070605 15:25:53 [Note] Recovering after a crash using adflow-bin 070605 15:25:53 [Note] Starting crash recovery... 070605 15:25:53 [Note] Crash recovery finished. 070605 15:25:53 [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 141571968 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. 070605 15:26:05InnoDB: Assertion failure in thread 2537847728 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=0x93965a0 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=0x974459dc, 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 0x84bde8 0x52993a 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 0x93a2110 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070605 15:26:05 mysqld restarted 070605 15:26: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. 070605 15:26: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... 070605 15:26:05 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 310592238. InnoDB: Doing recovery: scanned up to log sequence number 0 310592248 InnoDB: Last MySQL binlog file position 0 289139, file name ./adflow-bin.000146 070605 15:26:05 InnoDB: Started; log sequence number 0 310592248 070605 15:26:05 [Note] Recovering after a crash using adflow-bin 070605 15:26:05 [Note] Starting crash recovery... 070605 15:26:05 [Note] Crash recovery finished. 070605 15:26: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 141571968 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. 070605 15:26: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=0x9a3c0a0 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 0x9a483e0 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070605 15:26:18 mysqld restarted 070605 15:26: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. 070605 15:26: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... 070605 15:26:18 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 310592248. InnoDB: Doing recovery: scanned up to log sequence number 0 310592258 InnoDB: Last MySQL binlog file position 0 289139, file name ./adflow-bin.000146 070605 15:26:18 InnoDB: Started; log sequence number 0 310592258 070605 15:26:18 [Note] Recovering after a crash using adflow-bin 070605 15:26:18 [Note] Starting crash recovery... 070605 15:26:18 [Note] Crash recovery finished. 070605 15:26: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 141571968 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. 070605 15:26:31InnoDB: 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. InnoDB: Thread 3010313136 stopped in file sync0arr.c line 336 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=0xa0170a0 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=0x976129dc, 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 0x760de8 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 0xa0233e0 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070605 15:26:31 mysqld restarted 070605 15:26: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. 070605 15:26: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... 070605 15:26:31 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 310592268. InnoDB: Doing recovery: scanned up to log sequence number 0 310592268 InnoDB: Last MySQL binlog file position 0 289139, file name ./adflow-bin.000146 070605 15:26:31 InnoDB: Started; log sequence number 0 310592268 070605 15:26:31 [Note] Recovering after a crash using adflow-bin 070605 15:26:31 [Note] Starting crash recovery... 070605 15:26:31 [Note] Crash recovery finished. 070605 15:26:32 [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 141571968 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. 070605 15:26:56InnoDB: Assertion failure in thread 2539264944 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=0xa456de8 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=0x9759f9dc, 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 0xa4793e8 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campInnoDB: Thread 2974038960 stopped in file os0sync.c line 501 aign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070605 15:26:56 mysqld restarted 070605 15:26: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. 070605 15:26: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... 070605 15:26:57 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 310592278. InnoDB: Doing recovery: scanned up to log sequence number 0 310592278 InnoDB: Last MySQL binlog file position 0 289139, file name ./adflow-bin.000146 070605 15:26:57 InnoDB: Started; log sequence number 0 310592278 070605 15:26:57 [Note] Recovering after a crash using adflow-bin 070605 15:26:57 [Note] Starting crash recovery... 070605 15:26:57 [Note] Crash recovery finished. 070605 15:26: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 141571968 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. 070605 15:27:01InnoDB: 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=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=0x903c0a0 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 InnoDB: Thread 3010296752 stopped in file sync0arr.c line 336 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 0x90483e0 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070605 15:27:01 mysqld restarted 070605 15:27: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. 070605 15:27: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... 070605 15:27:01 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 310592278. InnoDB: Doing recovery: scanned up to log sequence number 0 310592288 InnoDB: Last MySQL binlog file position 0 289139, file name ./adflow-bin.000146 070605 15:27:01 InnoDB: Started; log sequence number 0 310592288 070605 15:27:01 [Note] Recovering after a crash using adflow-bin 070605 15:27:01 [Note] Starting crash recovery... 070605 15:27:01 [Note] Crash recovery finished. 070605 15:27:01 [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 141571968 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. 070605 15:27:08InnoDB: 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=0xa7d6400 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 0x4edde8 0x83f93a 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 sync0arr.c line 336 thd->query at 0xa7e2480 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070605 15:27:08 mysqld restarted 070605 15:27:08 [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. 070605 15:27: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... 070605 15:27:09 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 310592288. InnoDB: Doing recovery: scanned up to log sequence number 0 310592298 InnoDB: Last MySQL binlog file position 0 289139, file name ./adflow-bin.000146 070605 15:27:09 InnoDB: Started; log sequence number 0 310592298 070605 15:27:09 [Note] Recovering after a crash using adflow-bin 070605 15:27:09 [Note] Starting crash recovery... 070605 15:27:09 [Note] Crash recovery finished. 070605 15:27: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 136460160 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. 070611 8:54:25InnoDB: Assertion failure in thread 2521426864 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=55 max_connections=100 threads_connected=50 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=0x8e8f108 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=0x9649c9dc, 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 0xb77de8 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 0x8cdb718 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr thd->thread_id=4893 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 070611 08:54:25 mysqld restarted 070611 8:54: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. 070611 8:54: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... 070611 8:54:26 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 313080663. InnoDB: Doing recovery: scanned up to log sequence number 0 313080663 InnoDB: Last MySQL binlog file position 0 2947842, file name ./adflow-bin.000153 070611 8:54:26 InnoDB: Started; log sequence number 0 313080663 070611 8:54:26 [Note] Recovering after a crash using adflow-bin 070611 8:54:26 [Note] Starting crash recovery... 070611 8:54:26 [Note] Crash recovery finished. 070611 8:54:26 [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 136460160 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. 070611 8:54:37InnoDB: 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=6 max_connections=100 threads_connected=6 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=0x8e9b0a0 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 0x115de8 0x1fd93a 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 3010309040 stopped in file ut0mem.c line 230 thd->query at 0x8ea73e0 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070611 08:54:37 mysqld restarted 070611 8:54:37 [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. 070611 8:54:37 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... 070611 8:54:37 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 313080663. InnoDB: Doing recovery: scanned up to log sequence number 0 313080673 InnoDB: Last MySQL binlog file position 0 2947842, file name ./adflow-bin.000153 070611 8:54:37 InnoDB: Started; log sequence number 0 313080673 070611 8:54:37 [Note] Recovering after a crash using adflow-bin 070611 8:54:37 [Note] Starting crash recovery... 070611 8:54:37 [Note] Crash recovery finished. 070611 8:54:37 [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 136460160 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. 070611 8:54:51InnoDB: 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=0x8b760a0 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 0x6b8de8 0xd9193a 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 0x8b823e0 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070611 08:54:51 mysqld restarted 070611 8:54:51 [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. 070611 8:54:51 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... 070611 8:54:51 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 313080683. InnoDB: Doing recovery: scanned up to log sequence number 0 313080683 InnoDB: Last MySQL binlog file position 0 2947842, file name ./adflow-bin.000153 070611 8:54:51 InnoDB: Started; log sequence number 0 313080683 070611 8:54:51 [Note] Recovering after a crash using adflow-bin 070611 8:54:51 [Note] Starting crash recovery... 070611 8:54:51 [Note] Crash recovery finished. 070611 8:54: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 136460160 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. 070611 9:01:36InnoDB: Assertion failure in thread 2536909744 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=22 max_connections=100 threads_connected=15 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=0xabdbed8 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=0x973609dc, 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 0xd9dde8 0xb6e93a 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 0xac41580 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr thd->thread_id=460 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 070611 09:01:36 mysqld restarted 070611 9:01: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. 070611 9:01: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... 070611 9:01:37 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 313081619. InnoDB: Doing recovery: scanned up to log sequence number 0 313081619 InnoDB: Last MySQL binlog file position 0 644, file name ./adflow-bin.000156 070611 9:01:37 InnoDB: Started; log sequence number 0 313081619 070611 9:01:37 [Note] Recovering after a crash using adflow-bin 070611 9:01:37 [Note] Starting crash recovery... 070611 9:01:37 [Note] Crash recovery finished. 070611 9:01:37 [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 136460160 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. 070611 9:01:43InnoDB: 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=0x95070a0 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 0x73ede8 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 0x95133e0 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070611 09:01:43 mysqld restarted 070611 9:01: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. 070611 9:01: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... 070611 9:01:43 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 313081619. InnoDB: Doing recovery: scanned up to log sequence number 0 313081629 InnoDB: Last MySQL binlog file position 0 644, file name ./adflow-bin.000156 070611 9:01:43 InnoDB: Started; log sequence number 0 313081629 070611 9:01:43 [Note] Recovering after a crash using adflow-bin 070611 9:01:43 [Note] Starting crash recovery... 070611 9:01:43 [Note] Crash recovery finished. 070611 9:01: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 136460160 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. 070611 9:01:55InnoDB: 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. InnoDB: Thread 3010284464 stopped in file ut0mem.c line 230 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=0x9a860a0 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 0x145de8 0xa1193a 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 0x9a923e0 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070611 09:01:55 mysqld restarted 070611 9:01: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. 070611 9:01: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... 070611 9:01:55 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 313081629. InnoDB: Doing recovery: scanned up to log sequence number 0 313081639 InnoDB: Last MySQL binlog file position 0 644, file name ./adflow-bin.000156 070611 9:01:55 InnoDB: Started; log sequence number 0 313081639 070611 9:01:55 [Note] Recovering after a crash using adflow-bin 070611 9:01:55 [Note] Starting crash recovery... 070611 9:01:55 [Note] Crash recovery finished. 070611 9:01: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 189675392 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. 070611 9:02:13InnoDB: Assertion failure in thread 2539531184 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=0xa9e4c40 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=0x975e09dc, 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 0x1fede8 0x49d93a 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 0xaa0b7a0 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070611 09:02:13 mysqld restarted 070611 9:02:13 [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. 070611 9:02: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... 070611 9:02:13 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 313081649. InnoDB: Doing recovery: scanned up to log sequence number 0 313081649 InnoDB: Last MySQL binlog file position 0 644, file name ./adflow-bin.000156 070611 9:02:13 InnoDB: Started; log sequence number 0 313081649 070611 9:02:13 [Note] Recovering after a crash using adflow-bin 070611 9:02:13 [Note] Starting crash recovery... 070611 9:02:13 [Note] Crash recovery finished. 070611 9:02: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 189675392 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. 070611 9:40:13InnoDB: 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=21 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=0x9f470a0 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 0x1b6de8 0x29e93a 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 0x9f533e0 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070611 09:40:13 mysqld restarted 070611 9:40:13 [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. 070611 9:40: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... 070611 9:40:13 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 313156305. InnoDB: Doing recovery: scanned up to log sequence number 0 313156305 InnoDB: Last MySQL binlog file position 0 74466, file name ./adflow-bin.000160 070611 9:40:13 InnoDB: Started; log sequence number 0 313156305 070611 9:40:13 [Note] Recovering after a crash using adflow-bin 070611 9:40:13 [Note] Starting crash recovery... 070611 9:40:13 [Note] Crash recovery finished. 070611 9:40: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 76232576 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. 070611 9:40:16InnoDB: 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=0xa37c0a0 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 0x5a6de8 0x42f93a 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 ut0mem.c line 230 thd->query at 0xa3883e0 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070611 09:40:16 mysqld restarted 070611 9:40: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. 070611 9:40: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... 070611 9:40:16 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 313156344. InnoDB: Doing recovery: scanned up to log sequence number 0 313156354 InnoDB: Last MySQL binlog file position 0 74466, file name ./adflow-bin.000160 070611 9:40:16 InnoDB: Started; log sequence number 0 313156354 070611 9:40:16 [Note] Recovering after a crash using adflow-bin 070611 9:40:16 [Note] Starting crash recovery... 070611 9:40:16 [Note] Crash recovery finished. 070611 9:40: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 76232576 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. 070611 9:40:19InnoDB: 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=0xa209638 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 0xcb8de8 0x3d793a 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 3010317232 stopped in file sync0arr.c line 336 thd->query at 0xa231e68 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070611 09:40:19 mysqld restarted 070611 9:40: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. 070611 9:40: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... 070611 9:40:19 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 313156354. InnoDB: Doing recovery: scanned up to log sequence number 0 313156364 InnoDB: Last MySQL binlog file position 0 74466, file name ./adflow-bin.000160 070611 9:40:19 InnoDB: Started; log sequence number 0 313156364 070611 9:40:19 [Note] Recovering after a crash using adflow-bin 070611 9:40:19 [Note] Starting crash recovery... 070611 9:40:19 [Note] Crash recovery finished. 070611 9:40: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 76232576 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. 070611 9:53:12InnoDB: Assertion failure in thread 2539289520 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=8 max_connections=100 threads_connected=7 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=0x8b50350 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=0x975a59fc, 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 0x115de8 0xb7993a 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 0x8b5bc48 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070611 09:53:12 mysqld restarted 070611 9:53: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. 070611 9:53:12 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... 070611 9:53:12 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 313156857. InnoDB: Doing recovery: scanned up to log sequence number 0 313156857 InnoDB: Last MySQL binlog file position 0 271, file name ./adflow-bin.000163 070611 9:53:12 InnoDB: Started; log sequence number 0 313156857 070611 9:53:12 [Note] Recovering after a crash using adflow-bin 070611 9:53:12 [Note] Starting crash recovery... 070611 9:53:12 [Note] Crash recovery finished. 070611 9:53:12 [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=0x98e8638 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=0x9760f0dc, 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 0x9910e68 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070611 09:53:21 mysqld restarted 070611 9:53: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. 070611 9:53: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... 070611 9:53:21 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 313156857. InnoDB: Doing recovery: scanned up to log sequence number 0 313156867 InnoDB: Last MySQL binlog file position 0 271, file name ./adflow-bin.000163 070611 9:53:21 InnoDB: Started; log sequence number 0 313156867 070611 9:53:21 [Note] Recovering after a crash using adflow-bin 070611 9:53:21 [Note] Starting crash recovery... 070611 9:53:21 [Note] Crash recovery finished. 070611 9:53: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) 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=0x8d02638 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=0x9760f0dc, 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 0x8d2ae68 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070611 09:53:29 mysqld restarted 070611 9:53: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. 070611 9:53: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... 070611 9:53:29 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 313156867. InnoDB: Doing recovery: scanned up to log sequence number 0 313156877 InnoDB: Last MySQL binlog file position 0 271, file name ./adflow-bin.000163 070611 9:53:29 InnoDB: Started; log sequence number 0 313156877 070611 9:53:29 [Note] Recovering after a crash using adflow-bin 070611 9:53:29 [Note] Starting crash recovery... 070611 9:53:29 [Note] Crash recovery finished. 070611 9:53:30 [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 189675392 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. 070611 9:53:56InnoDB: 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=0xa1af780 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=0x975dc9fc, 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 0x5fdde8 0x33d93a 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 0xa1b2c08 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070611 09:53:56 mysqld restarted 070611 9:53: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. 070611 9:53: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... 070611 9:53:56 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 313156887. InnoDB: Doing recovery: scanned up to log sequence number 0 313156887 InnoDB: Last MySQL binlog file position 0 271, file name ./adflow-bin.000163 070611 9:53:56 InnoDB: Started; log sequence number 0 313156887 070611 9:53:56 [Note] Recovering after a crash using adflow-bin 070611 9:53:56 [Note] Starting crash recovery... 070611 9:53:56 [Note] Crash recovery finished. 070611 9:53: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) 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=0xa05f638 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=0x976120dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x82b5346 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x6c1de8 0xa9a93a 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 0xa087e68 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070611 09:54:07 mysqld restarted 070611 9:54: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. 070611 9:54: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... 070611 9:54:07 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 313156887. InnoDB: Doing recovery: scanned up to log sequence number 0 313156897 InnoDB: Last MySQL binlog file position 0 271, file name ./adflow-bin.000163 070611 9:54:07 InnoDB: Started; log sequence number 0 313156897 070611 9:54:07 [Note] Recovering after a crash using adflow-bin 070611 9:54:07 [Note] Starting crash recovery... 070611 9:54:07 [Note] Crash recovery finished. 070611 9:54: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 109983104 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. 070615 14:08:29InnoDB: Assertion failure in thread 2536668080 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=66 max_connections=100 threads_connected=52 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=0x9691a948 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=0x973259dc, 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 0x517de8 0xf4993a 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 0x8f4fba8 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr thd->thread_id=4350 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 070615 14:08:29 mysqld restarted 070615 14: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. 070615 14: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... 070615 14:08:30 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 316077515. InnoDB: Doing recovery: scanned up to log sequence number 0 316077515 InnoDB: Last MySQL binlog file position 0 2726139, file name ./adflow-bin.000168 070615 14:08:30 InnoDB: Started; log sequence number 0 316077515 070615 14:08:30 [Note] Recovering after a crash using adflow-bin 070615 14:08:30 [Note] Starting crash recovery... 070615 14:08:30 [Note] Crash recovery finished. 070615 14:08:30 [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 109983104 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. 070615 14:08:34InnoDB: 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=0x9838638 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 0x9860e68 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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. InnoDB: Thread 3010296752 stopped in file os0sync.c line 501 Number of processes running now: 0 070615 14:08:34 mysqld restarted 070615 14:08: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. 070615 14:08: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... 070615 14:08:34 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 316077515. InnoDB: Doing recovery: scanned up to log sequence number 0 316077525 InnoDB: Last MySQL binlog file position 0 2726139, file name ./adflow-bin.000168 070615 14:08:34 InnoDB: Started; log sequence number 0 316077525 070615 14:08:34 [Note] Recovering after a crash using adflow-bin 070615 14:08:34 [Note] Starting crash recovery... 070615 14:08:34 [Note] Crash recovery finished. 070615 14:08: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) 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=0xa13b638 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=0x9760d0dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x82b5346 0x8227824 0x81d0e1d 0x81c2b0f 0x81c9113 0x81c2aa2 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xa90de8 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 0xa163e68 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070615 14:09:24 mysqld restarted 070615 14:09:24 [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. 070615 14:09:24 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... 070615 14:09:24 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 316077535. InnoDB: Doing recovery: scanned up to log sequence number 0 316078636 070615 14:09:24 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 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 2109, file name ./adflow-bin.000170 070615 14:09:25 InnoDB: Started; log sequence number 0 316078636 070615 14:09:25 [Note] Recovering after a crash using adflow-bin 070615 14:09:25 [Note] Starting crash recovery... 070615 14:09:25 [Note] Crash recovery finished. 070615 14:09: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 109983104 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. 070615 14:13:23InnoDB: 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=8 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=0x8c0c870 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 0x321de8 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 0x974004b0 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 070615 14:13:23 mysqld restarted 070615 14:13: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. 070615 14:13:24 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... 070615 14:13:24 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 316079557. InnoDB: Doing recovery: scanned up to log sequence number 0 316079557 InnoDB: Last MySQL binlog file position 0 644, file name ./adflow-bin.000171 070615 14:13:24 InnoDB: Started; log sequence number 0 316079557 070615 14:13:24 [Note] Recovering after a crash using adflow-bin 070615 14:13:24 [Note] Starting crash recovery... 070615 14:13:24 [Note] Crash recovery finished. 070615 14:13:24 [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 109983104 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. 070615 15:40:51InnoDB: Assertion failure in thread 2539469744 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=38 max_connections=100 threads_connected=38 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=0xa8adc98 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=0x975d19dc, 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 0x2c1de8 0x46093a 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 0xa8f6a80 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr 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 070615 15:40:51 mysqld restarted 070615 15:40:51 [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. 070615 15:40:51 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... 070615 15:40:51 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 316733570. InnoDB: Doing recovery: scanned up to log sequence number 0 316733570 InnoDB: Last MySQL binlog file position 0 662679, file name ./adflow-bin.000172 070615 15:40:51 InnoDB: Started; log sequence number 0 316733570 070615 15:40:51 [Note] Recovering after a crash using adflow-bin 070615 15:40:51 [Note] Starting crash recovery... 070615 15:40:51 [Note] Crash recovery finished. 070615 15:40: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 188233088 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. 070615 16:03:01InnoDB: Assertion failure in thread 2537102256 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=14 max_connections=100 threads_connected=14 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=0x91ce588 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=0x9738f9dc, 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 0x91da2a0 = 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 , agency.isContract as agencyIsContract, advertiserBrand.isContract as advertiserBrandIsContract FROM campaign LEFT JOIN campaign_insertionOrder USING ( campaign_id ) LEFT JOIN insertionOr thd->thread_id=20 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.