Number of processes running now: 0 070615 16:03:01 mysqld restarted 070615 16:03: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. 070615 16:03: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... 070615 16:03:01 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 316737473. InnoDB: Doing recovery: scanned up to log sequence number 0 316737473 InnoDB: Last MySQL binlog file position 0 1956, file name ./adflow-bin.000173 070615 16:03:01 InnoDB: Started; log sequence number 0 316737473 070615 16:03:01 [Note] Recovering after a crash using adflow-bin 070615 16:03:01 [Note] Starting crash recovery... 070615 16:03:01 [Note] Crash recovery finished. 070615 16:03: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 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:15InnoDB: Assertion failure in thread 2538453936 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=0x90eee40 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=0x974d99dc, 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 InnoDB: Thread 3010280368 stopped in file ut0mem.c line 230 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0xdd4de8 0x9e193a 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 0x90fa7a0 = 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 16:03:15 mysqld restarted 070615 16:03: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. 070615 16:03: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... 070615 16:03:15 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 316737522. InnoDB: Doing recovery: scanned up to log sequence number 0 316737522 InnoDB: Last MySQL binlog file position 0 1956, file name ./adflow-bin.000173 070615 16:03:15 InnoDB: Started; log sequence number 0 316737522 070615 16:03:15 [Note] Recovering after a crash using adflow-bin 070615 16:03:15 [Note] Starting crash recovery... 070615 16:03:15 [Note] Crash recovery finished. 070615 16:03: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 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 16:04:36InnoDB: Assertion failure in thread 2539510704 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=0x8bf3e88 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=0x975db9dc, 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 0x2fdde8 0x94493a 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 0x8bff330 = 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 16:04:36 mysqld restarted 070615 16:04: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. 070615 16:04: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... 070615 16:04:36 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 316737950. InnoDB: Doing recovery: scanned up to log sequence number 0 316737950 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000175 070615 16:04:36 InnoDB: Started; log sequence number 0 316737950 070615 16:04:36 [Note] Recovering after a crash using adflow-bin 070615 16:04:36 [Note] Starting crash recovery... 070615 16:04:36 [Note] Crash recovery finished. 070615 16:04: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 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 16:45:02InnoDB: 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=10 max_connections=100 threads_connected=10 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9785388 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 0xd02de8 0xb8a93a 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 0x979ae28 = 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 16:45:02 mysqld restarted 070615 16:45:02 [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 16:45:02 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 16:45:02 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 316738779. InnoDB: Doing recovery: scanned up to log sequence number 0 316738779 InnoDB: Last MySQL binlog file position 0 645, file name ./adflow-bin.000176 070615 16:45:02 InnoDB: Started; log sequence number 0 316738779 070615 16:45:02 [Note] Recovering after a crash using adflow-bin 070615 16:45:02 [Note] Starting crash recovery... 070615 16:45:02 [Note] Crash recovery finished. 070615 16:45: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 154678656 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. 070618 13:25:44InnoDB: Assertion failure in thread 2535545776 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=54 max_connections=100 threads_connected=53 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=0x9354638 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=0x972139dc, 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 0x9aede8 0xe1293a 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 0x967f1d8 = 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=297 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 070618 13:25:44 mysqld restarted 070618 13:25: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. 070618 13:25: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... 070618 13:25:45 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 317142925. InnoDB: Doing recovery: scanned up to log sequence number 0 317142925 InnoDB: Last MySQL binlog file position 0 401549, file name ./adflow-bin.000177 070618 13:25:45 InnoDB: Started; log sequence number 0 317142925 070618 13:25:45 [Note] Recovering after a crash using adflow-bin 070618 13:25:45 [Note] Starting crash recovery... 070618 13:25:45 [Note] Crash recovery finished. 070618 13:25: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 154678656 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. 070618 13:25:49InnoDB: 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=0x8fd50a0 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... InnoDB: Thread 3010300848 stopped in file ut0mem.c line 230 thd->query at 0x8fe13e0 = 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 070618 13:25:49 mysqld restarted 070618 13:25:49 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070618 13:25:49 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070618 13:25:49 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 317142925. InnoDB: Doing recovery: scanned up to log sequence number 0 317142935 InnoDB: Last MySQL binlog file position 0 401549, file name ./adflow-bin.000177 070618 13:25:49 InnoDB: Started; log sequence number 0 317142935 070618 13:25:49 [Note] Recovering after a crash using adflow-bin 070618 13:25:49 [Note] Starting crash recovery... 070618 13:25:49 [Note] Crash recovery finished. 070618 13:25:49 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 154678656 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. 070618 13:25:53InnoDB: 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 InnoDB: Thread 3010309040 stopped in file os0sync.c line 501 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=0xa0390a0 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 0xfbdde8 0x3ae93a 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 0xa0453e0 = 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 070618 13:25:53 mysqld restarted 070618 13: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. 070618 13:25:54 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070618 13:25:54 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 317142935. InnoDB: Doing recovery: scanned up to log sequence number 0 317142945 InnoDB: Last MySQL binlog file position 0 401549, file name ./adflow-bin.000177 070618 13:25:54 InnoDB: Started; log sequence number 0 317142945 070618 13:25:54 [Note] Recovering after a crash using adflow-bin 070618 13:25:54 [Note] Starting crash recovery... 070618 13:25:54 [Note] Crash recovery finished. 070618 13:25:54 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 190592384 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. 070620 10:05:00InnoDB: Assertion failure in thread 2524367792 in file fil0fil.c line 3959 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=402653184 read_buffer_size=2093056 max_used_connections=67 max_connections=100 threads_connected=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=0xaa6d698 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=0x9676a9dc, 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 0x1a7de8 0x66393a 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 0xab53cf0 = 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=519 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 070620 10:05:00 mysqld restarted 070620 10:05: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. 070620 10:05: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... 070620 10:05:01 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 318824827. InnoDB: Doing recovery: scanned up to log sequence number 0 318824827 InnoDB: Last MySQL binlog file position 0 1616376, file name ./adflow-bin.000180 070620 10:05:01 InnoDB: Started; log sequence number 0 318824827 070620 10:05:01 [Note] Recovering after a crash using adflow-bin 070620 10:05:01 [Note] Starting crash recovery... 070620 10:05:01 [Note] Crash recovery finished. 070620 10:05: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 190592384 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. 070620 10:05:10InnoDB: Assertion failure in thread 2539711408 in file fil0fil.c line 3959 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=402653184 read_buffer_size=2093056 max_used_connections=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=0x973e638 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 0x58cde8 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 0x9766e68 = 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 070620 10:05:10 mysqld restarted 070620 10:05:10 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070620 10:05:10 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070620 10:05:11 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 318824827. InnoDB: Doing recovery: scanned up to log sequence number 0 318824837 InnoDB: Last MySQL binlog file position 0 1616376, file name ./adflow-bin.000180 070620 10:05:11 InnoDB: Started; log sequence number 0 318824837 070620 10:05:11 [Note] Recovering after a crash using adflow-bin 070620 10:05:11 [Note] Starting crash recovery... 070620 10:05:11 [Note] Crash recovery finished. 070620 10:05:11 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 190592384 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. 070620 10:05:30InnoDB: Assertion failure in thread 2539486128 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=0x9ff5e88 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=0x975d59dc, 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 0x7ecde8 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 0xa01d060 = 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 070620 10:05:30 mysqld restarted 070620 10:05: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. 070620 10:05: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... 070620 10:05:30 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 318825721. InnoDB: Doing recovery: scanned up to log sequence number 0 318825721 InnoDB: Last MySQL binlog file position 0 545, file name ./adflow-bin.000182 070620 10:05:30 InnoDB: Started; log sequence number 0 318825721 070620 10:05:30 [Note] Recovering after a crash using adflow-bin 070620 10:05:30 [Note] Starting crash recovery... 070620 10:05:30 [Note] Crash recovery finished. 070620 10:05: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 189347200 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. 070620 10:06:41InnoDB: Assertion failure in thread 2538904496 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. InnoDB: Thread 3010284464 stopped in file ut0mem.c line 230 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=7 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=0x968b948 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=0x975479dc, 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 0x935de8 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 0x96b3820 = 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=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 070620 10:06:41 mysqld restarted 070620 10:06:41 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070620 10:06:41 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070620 10:06:41 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 318825731. InnoDB: Doing recovery: scanned up to log sequence number 0 318825731 InnoDB: Last MySQL binlog file position 0 545, file name ./adflow-bin.000182 070620 10:06:41 InnoDB: Started; log sequence number 0 318825731 070620 10:06:41 [Note] Recovering after a crash using adflow-bin 070620 10:06:41 [Note] Starting crash recovery... 070620 10:06:41 [Note] Crash recovery finished. 070620 10:06:42 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 189347200 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. 070620 10:07:07InnoDB: 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=0xa4b0638 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 0xa4d8e68 = 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 070620 10:07:07 mysqld restarted 070620 10:07: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. 070620 10:07: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... 070620 10:07:07 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 318825741. InnoDB: Doing recovery: scanned up to log sequence number 0 318826462 070620 10:07:07 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 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 644, file name ./adflow-bin.000184 070620 10:07:08 InnoDB: Started; log sequence number 0 318826462 070620 10:07:08 [Note] Recovering after a crash using adflow-bin 070620 10:07:08 [Note] Starting crash recovery... 070620 10:07:08 [Note] Crash recovery finished. 070620 10:07:08 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 190592384 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. 070620 10:07:28InnoDB: Assertion failure in thread 2539731888 in file fil0fil.c line 3959 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=402653184 read_buffer_size=2093056 max_used_connections=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9be1638 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 0x6d6de8 0x2dd93a 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 sync0arr.c line 336 thd->query at 0x9c09e68 = 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 070620 10:07:28 mysqld restarted 070620 10:07:28 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070620 10:07:28 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070620 10:07:28 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 318826472. InnoDB: Doing recovery: scanned up to log sequence number 0 318826472 InnoDB: Last MySQL binlog file position 0 644, file name ./adflow-bin.000184 070620 10:07:28 InnoDB: Started; log sequence number 0 318826472 070620 10:07:28 [Note] Recovering after a crash using adflow-bin 070620 10:07:28 [Note] Starting crash recovery... 070620 10:07:28 [Note] Crash recovery finished. 070620 10:07:28 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 190592384 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. 070620 10:07:51InnoDB: Assertion failure in thread 2538474416 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. InnoDB: Thread 3010300848 stopped in file sync0arr.c line 336 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=0x8d83e58 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=0x974de9fc, 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 0x8d8f9c8 = 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 070620 10:07:51 mysqld restarted 070620 10:07: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. 070620 10:07: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... 070620 10:07:52 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 318826482. InnoDB: Doing recovery: scanned up to log sequence number 0 318826482 InnoDB: Last MySQL binlog file position 0 644, file name ./adflow-bin.000184 070620 10:07:52 InnoDB: Started; log sequence number 0 318826482 070620 10:07:52 [Note] Recovering after a crash using adflow-bin 070620 10:07:52 [Note] Starting crash recovery... 070620 10:07:52 [Note] Crash recovery finished. 070620 10:07: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 190592384 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. 070620 10:08:13InnoDB: 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=0x9ae5638 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 0x9b0de68 = 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 070620 10:08:13 mysqld restarted 070620 10:08: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. 070620 10:08: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... 070620 10:08:13 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 318826508. InnoDB: Doing recovery: scanned up to log sequence number 0 318826508 InnoDB: Last MySQL binlog file position 0 644, file name ./adflow-bin.000184 070620 10:08:14 InnoDB: Started; log sequence number 0 318826508 070620 10:08:14 [Note] Recovering after a crash using adflow-bin 070620 10:08:14 [Note] Starting crash recovery... 070620 10:08:14 [Note] Crash recovery finished. 070620 10:08: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 190592384 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. 070620 10:08:52InnoDB: 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=0x8acc638 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 0xfc0de8 0x25093a 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 0x8af4e68 = 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 070620 10:08:52 mysqld restarted 070620 10:08: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. 070620 10:08: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... 070620 10:08:52 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 318826508. InnoDB: Doing recovery: scanned up to log sequence number 0 318826518 InnoDB: Last MySQL binlog file position 0 644, file name ./adflow-bin.000184 070620 10:08:52 InnoDB: Started; log sequence number 0 318826518 070620 10:08:52 [Note] Recovering after a crash using adflow-bin 070620 10:08:52 [Note] Starting crash recovery... 070620 10:08:52 [Note] Crash recovery finished. 070620 10:08: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 190592384 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. 070620 10:12:05InnoDB: Assertion failure in thread 2537061296 in file fil0fil.c line 3959 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=402653184 read_buffer_size=2093056 max_used_connections=9 max_connections=100 threads_connected=9 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x91f1070 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=0x973859fc, 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 0x29ade8 0x8b193a 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 0x91fcb68 = 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=10 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 0 070620 10:12:05 mysqld restarted 070620 10:12: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. 070620 10:12: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... 070620 10:12:05 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 318826995. InnoDB: Doing recovery: scanned up to log sequence number 0 318827358 070620 10:12:05 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 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 545, file name ./adflow-bin.000189 070620 10:12:05 InnoDB: Started; log sequence number 0 318827358 070620 10:12:05 [Note] Recovering after a crash using adflow-bin 070620 10:12:05 [Note] Starting crash recovery... 070620 10:12:05 [Note] Crash recovery finished. 070620 10:12: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 190592384 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. 070620 10:12:22InnoDB: 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=0x9386638 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 0x87fde8 0xdce93a 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 0x93aee68 = 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 070620 10:12:22 mysqld restarted 070620 10:12:22 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070620 10:12:22 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070620 10:12:22 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 318827386. InnoDB: Doing recovery: scanned up to log sequence number 0 318827396 InnoDB: Last MySQL binlog file position 0 545, file name ./adflow-bin.000189 070620 10:12:22 InnoDB: Started; log sequence number 0 318827396 070620 10:12:22 [Note] Recovering after a crash using adflow-bin 070620 10:12:22 [Note] Starting crash recovery... 070620 10:12:22 [Note] Crash recovery finished. 070620 10:12:22 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 193803648 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. 070620 10:30:18InnoDB: Assertion failure in thread 2538118064 in file fil0fil.c line 3959 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=402653184 read_buffer_size=2093056 max_used_connections=9 max_connections=100 threads_connected=9 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9610590 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=0x974879dc, 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 0x817de8 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 0x964a2d0 = 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=25 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 070620 10:30:19 mysqld restarted 070620 10:30: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. 070620 10:30: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... 070620 10:30:19 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 318829969. InnoDB: Doing recovery: scanned up to log sequence number 0 318829969 InnoDB: Last MySQL binlog file position 0 1438, file name ./adflow-bin.000191 070620 10:30:19 InnoDB: Started; log sequence number 0 318829969 070620 10:30:19 [Note] Recovering after a crash using adflow-bin 070620 10:30:19 [Note] Starting crash recovery... 070620 10:30:19 [Note] Crash recovery finished. 070620 10:30: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 156710272 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. 070620 10:30:24InnoDB: 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=0x952c638 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 0x47ede8 0x9d493a 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 0x9554e68 = 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 070620 10:30:24 mysqld restarted 070620 10:30: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. 070620 10:30: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... 070620 10:30:24 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 318829969. InnoDB: Doing recovery: scanned up to log sequence number 0 318829979 InnoDB: Last MySQL binlog file position 0 1438, file name ./adflow-bin.000191 070620 10:30:24 InnoDB: Started; log sequence number 0 318829979 070620 10:30:24 [Note] Recovering after a crash using adflow-bin 070620 10:30:24 [Note] Starting crash recovery... 070620 10:30:24 [Note] Crash recovery finished. 070620 10:30: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 156710272 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. 070620 10:30:33InnoDB: 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=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=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 0xd9ade8 0x21d93a 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 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 , 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 070620 10:30:33 mysqld restarted 070620 10:30: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. 070620 10:30:33 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070620 10:30:33 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 318829979. InnoDB: Doing recovery: scanned up to log sequence number 0 318829989 InnoDB: Last MySQL binlog file position 0 1438, file name ./adflow-bin.000191 070620 10:30:33 InnoDB: Started; log sequence number 0 318829989 070620 10:30:33 [Note] Recovering after a crash using adflow-bin 070620 10:30:33 [Note] Starting crash recovery... 070620 10:30:33 [Note] Crash recovery finished. 070620 10:30:33 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 156710272 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. 070620 10:30: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=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=0x9ee7638 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 0xc0ade8 0xd4693a 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 0x9f0fe68 = 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, InnoDB: Thread 2974059440 stopped in file os0sync.c line 501 InnoDB: Thread 2963569584 stopped in file ../include/sync0sync.ic line 111 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 070620 10:30:37 mysqld restarted 070620 10:30: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. 070620 10:30: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... 070620 10:30:37 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 318829989. InnoDB: Doing recovery: scanned up to log sequence number 0 318829999 InnoDB: Last MySQL binlog file position 0 1438, file name ./adflow-bin.000191 070620 10:30:37 InnoDB: Started; log sequence number 0 318829999 070620 10:30:37 [Note] Recovering after a crash using adflow-bin 070620 10:30:37 [Note] Starting crash recovery... 070620 10:30:37 [Note] Crash recovery finished. 070620 10:30: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 156710272 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. 070620 10:31:57InnoDB: Assertion failure in thread 2539518896 in file fil0fil.c line 3959 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=402653184 read_buffer_size=2093056 max_used_connections=2 max_connections=100 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8ca5538 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 0x592de8 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 0x8d4b978 = 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 070620 10:31:57 mysqld restarted 070620 10:31:57 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070620 10:31:58 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070620 10:31:58 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 318830009. InnoDB: Doing recovery: scanned up to log sequence number 0 318830009 InnoDB: Last MySQL binlog file position 0 1438, file name ./adflow-bin.000191 070620 10:31:58 InnoDB: Started; log sequence number 0 318830009 070620 10:31:58 [Note] Recovering after a crash using adflow-bin 070620 10:31:58 [Note] Starting crash recovery... 070620 10:31:58 [Note] Crash recovery finished. 070620 10:31: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) 070621 5:59:17 [Note] /usr/local/mysql/bin/mysqld: Normal shutdown 070621 5:59:19 InnoDB: Starting shutdown... 070621 5:59:22 InnoDB: Shutdown completed; log sequence number 0 319256890 070621 5:59:22 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete 070621 05:59:22 mysqld ended 070621 06:00:23 mysqld started 070621 6:00: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. 070621 6:00:23 InnoDB: Started; log sequence number 0 319256890 070621 6:00: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 193803648 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. 070621 7:09:40InnoDB: 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=0x8f28638 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 0x8f50e68 = 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 070621 07:09:40 mysqld restarted 070621 7:09: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. 070621 7:09: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... 070621 7:09:41 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319257318. InnoDB: Doing recovery: scanned up to log sequence number 0 319257318 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000197 070621 7:09:41 InnoDB: Started; log sequence number 0 319257318 070621 7:09:41 [Note] Recovering after a crash using adflow-bin 070621 7:09:41 [Note] Starting crash recovery... 070621 7:09:41 [Note] Crash recovery finished. 070621 7:09:41 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 193803648 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. 070621 7:10:06InnoDB: Assertion failure in thread 2538388400 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=0x94f12f0 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=0x974c99fc, 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 0xcffde8 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 0x9519b20 = 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 070621 07:10:06 mysqld restarted 070621 7:10: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. 070621 7:10: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... 070621 7:10:06 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319257318. InnoDB: Doing recovery: scanned up to log sequence number 0 319257328 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000197 070621 7:10:06 InnoDB: Started; log sequence number 0 319257328 070621 7:10:06 [Note] Recovering after a crash using adflow-bin 070621 7:10:06 [Note] Starting crash recovery... 070621 7:10:06 [Note] Crash recovery finished. 070621 7:10: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 193803648 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. 070621 7:10:32InnoDB: 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=0xa0a6638 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 0xb77de8 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 0xa0cee68 = 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 070621 07:10:32 mysqld restarted 070621 7:10: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. 070621 7:10: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... 070621 7:10:32 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319257338. InnoDB: Doing recovery: scanned up to log sequence number 0 319257338 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000197 070621 7:10:32 InnoDB: Started; log sequence number 0 319257338 070621 7:10:32 [Note] Recovering after a crash using adflow-bin 070621 7:10:32 [Note] Starting crash recovery... 070621 7:10:32 [Note] Crash recovery finished. 070621 7:10: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 193803648 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. 070621 7:11:02InnoDB: 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=0xa11f638 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 0xcc6de8 0xc5693a 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 0xa147e68 = 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 070621 07:11:02 mysqld restarted 070621 7:11:02 [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. 070621 7:11:02 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... 070621 7:11:02 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319257348. InnoDB: Doing recovery: scanned up to log sequence number 0 319257348 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000197 070621 7:11:02 InnoDB: Started; log sequence number 0 319257348 070621 7:11:02 [Note] Recovering after a crash using adflow-bin 070621 7:11:02 [Note] Starting crash recovery... 070621 7:11:02 [Note] Crash recovery finished. 070621 7:11: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 193803648 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. 070621 7:11:46InnoDB: 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=0x9a13638 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 0xc2dde8 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 0x9a3be68 = 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 070621 07:11:46 mysqld restarted 070621 7:11:46 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070621 7:11: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... 070621 7:11:46 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319257348. InnoDB: Doing recovery: scanned up to log sequence number 0 319257358 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000197 070621 7:11:46 InnoDB: Started; log sequence number 0 319257358 070621 7:11:46 [Note] Recovering after a crash using adflow-bin 070621 7:11:46 [Note] Starting crash recovery... 070621 7:11:46 [Note] Crash recovery finished. 070621 7:11: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 193803648 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. 070621 7:13:03InnoDB: Assertion failure in thread 2539715504 in file fil0fil.c line 3959 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. InnoDB: Thread 3010292656 stopped in file sync0arr.c line 336 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=0x9a11638 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 0x115de8 0x7be93a 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 0x9a39e68 = 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 070621 07:13:03 mysqld restarted 070621 7:13: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. 070621 7:13: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... 070621 7:13:03 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319257368. InnoDB: Doing recovery: scanned up to log sequence number 0 319257368 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000197 070621 7:13:03 InnoDB: Started; log sequence number 0 319257368 070621 7:13:03 [Note] Recovering after a crash using adflow-bin 070621 7:13:03 [Note] Starting crash recovery... 070621 7:13:03 [Note] Crash recovery finished. 070621 7:13: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 193803648 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. 070621 7:15:27InnoDB: 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=0x97e3638 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 0x828de8 0x2de93a 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 0x980be68 = 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 070621 07:15:27 mysqld restarted 070621 7:15: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. 070621 7:15:28 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070621 7:15:28 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319257368. InnoDB: Doing recovery: scanned up to log sequence number 0 319257378 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000197 070621 7:15:28 InnoDB: Started; log sequence number 0 319257378 070621 7:15:28 [Note] Recovering after a crash using adflow-bin 070621 7:15:28 [Note] Starting crash recovery... 070621 7:15:28 [Note] Crash recovery finished. 070621 7:15:28 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 193803648 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. 070621 7:26:11InnoDB: 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=0x9c04638 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 0xbf9de8 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 0x9c2ce68 = 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 070621 07:26:11 mysqld restarted 070621 7:26:11 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070621 7:26:11 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070621 7:26:12 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319257388. InnoDB: Doing recovery: scanned up to log sequence number 0 319257388 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000197 070621 7:26:12 InnoDB: Started; log sequence number 0 319257388 070621 7:26:12 [Note] Recovering after a crash using adflow-bin 070621 7:26:12 [Note] Starting crash recovery... 070621 7:26:12 [Note] Crash recovery finished. 070621 7:26: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) InnoDB: Error: trying to access page number 193803648 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. 070621 7:30:42InnoDB: 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=0xa9c5638 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 0xf37de8 0xd3093a 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 0xa9ede68 = 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 070621 07:30:42 mysqld restarted 070621 7:30: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. 070621 7:30: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... 070621 7:30:42 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319257398. InnoDB: Doing recovery: scanned up to log sequence number 0 319257398 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000197 070621 7:30:42 InnoDB: Started; log sequence number 0 319257398 070621 7:30:42 [Note] Recovering after a crash using adflow-bin 070621 7:30:42 [Note] Starting crash recovery... 070621 7:30:42 [Note] Crash recovery finished. 070621 7:30:42 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 189150592 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. 070621 7:31:19InnoDB: 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=0xa708638 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 0xf6ede8 0x62693a 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 0xa730e68 = 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 070621 07:31:19 mysqld restarted 070621 7:31: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. 070621 7:31: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... 070621 7:31:20 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319257408. InnoDB: Doing recovery: scanned up to log sequence number 0 319257408 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000197 070621 7:31:20 InnoDB: Started; log sequence number 0 319257408 070621 7:31:20 [Note] Recovering after a crash using adflow-bin 070621 7:31:20 [Note] Starting crash recovery... 070621 7:31:20 [Note] Crash recovery finished. 070621 7:31:20 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 163329408 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. 070621 7:57:09InnoDB: 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 InnoDB: Thread 3010304944 stopped in file os0sync.c line 501 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=0x9cec638 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x976109dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x380de8 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 0x9d14e68 = 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 070621 07:57:10 mysqld restarted 070621 7:57:10 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070621 7:57:10 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070621 7:57:10 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319258065. InnoDB: Doing recovery: scanned up to log sequence number 0 319258065 InnoDB: Last MySQL binlog file position 0 644, file name ./adflow-bin.000207 070621 7:57:10 InnoDB: Started; log sequence number 0 319258065 070621 7:57:10 [Note] Recovering after a crash using adflow-bin 070621 7:57:10 [Note] Starting crash recovery... 070621 7:57:10 [Note] Crash recovery finished. 070621 7:57:10 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 193803648 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. 070621 7:57:39InnoDB: 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=0x8d13638 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 0x962de8 0x8ed93a 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 0x8d3be68 = 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 070621 07:57:39 mysqld restarted 070621 7:57:39 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070621 7:57:39 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070621 7:57:39 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319258065. InnoDB: Doing recovery: scanned up to log sequence number 0 319258493 070621 7:57:39 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000208 070621 7:57:40 InnoDB: Started; log sequence number 0 319258493 070621 7:57:40 [Note] Recovering after a crash using adflow-bin 070621 7:57:40 [Note] Starting crash recovery... 070621 7:57:40 [Note] Crash recovery finished. 070621 7:57: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) 070621 7:58:13 [Note] /usr/local/mysql/bin/mysqld: Normal shutdown 070621 7:58:13 InnoDB: Starting shutdown... 070621 7:58:16 InnoDB: Shutdown completed; log sequence number 0 319258493 070621 7:58:16 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete 070621 07:58:16 mysqld ended 070621 08:01:26 mysqld started 070621 8:01:28 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070621 8:01:28 InnoDB: Started; log sequence number 0 319258493 070621 8:01:29 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 193803648 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. 070621 8:05:30InnoDB: 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=0xa1c6600 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 0x70fde8 0xdb793a 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 0xa1eee30 = 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 070621 08:05:30 mysqld restarted 070621 8:05: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. 070621 8:05: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... 070621 8:05:31 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319258921. InnoDB: Doing recovery: scanned up to log sequence number 0 319258921 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000210 070621 8:05:31 InnoDB: Started; log sequence number 0 319258921 070621 8:05:31 [Note] Recovering after a crash using adflow-bin 070621 8:05:31 [Note] Starting crash recovery... 070621 8:05:31 [Note] Crash recovery finished. 070621 8:05: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 193803648 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. 070621 8:05:45InnoDB: 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=0xa62e638 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 0xe58de8 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 0xa656e68 = 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 070621 08:05:45 mysqld restarted 070621 8:05:46 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070621 8:05: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... 070621 8:05:46 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319258931. InnoDB: Doing recovery: scanned up to log sequence number 0 319258931 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000210 070621 8:05:46 InnoDB: Started; log sequence number 0 319258931 070621 8:05:46 [Note] Recovering after a crash using adflow-bin 070621 8:05:46 [Note] Starting crash recovery... 070621 8:05:46 [Note] Crash recovery finished. 070621 8:05: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 193803648 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. 070621 8:05: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. 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=0xa2cd638 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 0x65bde8 0x24f93a 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 0xa2f5e68 = 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 070621 08:05:55 mysqld restarted 070621 8:05: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. 070621 8:05: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... 070621 8:05:55 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319258941. InnoDB: Doing recovery: scanned up to log sequence number 0 319258941 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000210 070621 8:05:55 InnoDB: Started; log sequence number 0 319258941 070621 8:05:55 [Note] Recovering after a crash using adflow-bin 070621 8:05:55 [Note] Starting crash recovery... 070621 8:05:55 [Note] Crash recovery finished. 070621 8:05: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 193803648 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. 070621 8:06:05InnoDB: 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=0x9d46638 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 0x3aede8 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 0x9d6ee68 = 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 070621 08:06:05 mysqld restarted 070621 8:06: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. 070621 8:06: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... 070621 8:06:05 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319258941. InnoDB: Doing recovery: scanned up to log sequence number 0 319258951 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000210 070621 8:06:05 InnoDB: Started; log sequence number 0 319258951 070621 8:06:05 [Note] Recovering after a crash using adflow-bin 070621 8:06:05 [Note] Starting crash recovery... 070621 8:06:05 [Note] Crash recovery finished. 070621 8:06: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 193803648 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. 070621 8:06:17InnoDB: 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=0x9598638 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 0x95c0e68 = 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 070621 08:06:17 mysqld restarted 070621 8:06: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. 070621 8:06: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... 070621 8:06:17 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319258951. InnoDB: Doing recovery: scanned up to log sequence number 0 319258961 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000210 070621 8:06:17 InnoDB: Started; log sequence number 0 319258961 070621 8:06:17 [Note] Recovering after a crash using adflow-bin 070621 8:06:17 [Note] Starting crash recovery... 070621 8:06:17 [Note] Crash recovery finished. 070621 8:06: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 190592384 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. 070621 9:16:12InnoDB: Assertion failure in thread 2539322288 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=35 max_connections=100 threads_connected=35 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9789f18 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=0x975ad9dc, 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 0x268de8 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 0x97a90e0 = 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=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 070621 09:16:12 mysqld restarted 070621 9:16: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. 070621 9:16: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... 070621 9:16:13 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319562901. InnoDB: Doing recovery: scanned up to log sequence number 0 319562901 InnoDB: Last MySQL binlog file position 0 161142, file name ./adflow-bin.000215 070621 9:16:13 InnoDB: Started; log sequence number 0 319562901 070621 9:16:13 [Note] Recovering after a crash using adflow-bin 070621 9:16:13 [Note] Starting crash recovery... 070621 9:16:13 [Note] Crash recovery finished. 070621 9:16: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 193803648 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. 070621 9:16:22InnoDB: Assertion failure in thread 2537237424 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=0x8cc2700 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=0x973b09dc, 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 0xecede8 0x82993a 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 0x8cd7d10 = 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=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 070621 09:16:22 mysqld restarted 070621 9:16:22 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070621 9:16:22 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070621 9:16:22 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319562901. InnoDB: Doing recovery: scanned up to log sequence number 0 319562911 InnoDB: Last MySQL binlog file position 0 161142, file name ./adflow-bin.000215 070621 9:16:22 InnoDB: Started; log sequence number 0 319562911 070621 9:16:22 [Note] Recovering after a crash using adflow-bin 070621 9:16:22 [Note] Starting crash recovery... 070621 9:16:22 [Note] Crash recovery finished. 070621 9:16:23 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 193803648 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. 070621 9:16:52InnoDB: Assertion failure in thread 2539510704 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=0xa2a0768 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=0x975db9dc, 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 0xd48de8 0x21e93a 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 0xa2b5f58 = 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 070621 09:16:52 mysqld restarted 070621 9:16: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. 070621 9:16: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... 070621 9:16:52 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319562921. InnoDB: Doing recovery: scanned up to log sequence number 0 319562921 InnoDB: Last MySQL binlog file position 0 161142, file name ./adflow-bin.000215 070621 9:16:52 InnoDB: Started; log sequence number 0 319562921 070621 9:16:52 [Note] Recovering after a crash using adflow-bin 070621 9:16:52 [Note] Starting crash recovery... 070621 9:16:52 [Note] Crash recovery finished. 070621 9:16: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 193803648 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. 070621 9:17:00InnoDB: 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=0xa468638 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 0x2e0de8 0x22893a 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 0xa490e68 = 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 070621 09:17:00 mysqld restarted 070621 9:17: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. 070621 9:17: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... 070621 9:17:01 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319562921. InnoDB: Doing recovery: scanned up to log sequence number 0 319562931 InnoDB: Last MySQL binlog file position 0 161142, file name ./adflow-bin.000215 070621 9:17:01 InnoDB: Started; log sequence number 0 319562931 070621 9:17:01 [Note] Recovering after a crash using adflow-bin 070621 9:17:01 [Note] Starting crash recovery... 070621 9:17:01 [Note] Crash recovery finished. 070621 9:17: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 193803648 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. 070621 9:18:06InnoDB: Assertion failure in thread 2539310000 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=0x91ee3b0 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=0x975aa9dc, 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 0xc39de8 0x81f93a 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 0x91f9858 = 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=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 070621 09:18:06 mysqld restarted 070621 9:18: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. 070621 9:18: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... 070621 9:18:07 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319563359. InnoDB: Doing recovery: scanned up to log sequence number 0 319563359 InnoDB: Last MySQL binlog file position 0 372, file name ./adflow-bin.000219 070621 9:18:07 InnoDB: Started; log sequence number 0 319563359 070621 9:18:07 [Note] Recovering after a crash using adflow-bin 070621 9:18:07 [Note] Starting crash recovery... 070621 9:18:07 [Note] Crash recovery finished. 070621 9:18: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 193803648 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. 070621 9:27:20InnoDB: 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=9 max_connections=100 threads_connected=8 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8e56638 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 0x8e7ee68 = 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 070621 09:27:20 mysqld restarted 070621 9:27: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. 070621 9:27: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... 070621 9:27:20 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319564089. InnoDB: Doing recovery: scanned up to log sequence number 0 319564407 070621 9:27:20 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 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 919, file name ./adflow-bin.000220 070621 9:27:21 InnoDB: Started; log sequence number 0 319564407 070621 9:27:21 [Note] Recovering after a crash using adflow-bin 070621 9:27:21 [Note] Starting crash recovery... 070621 9:27:21 [Note] Crash recovery finished. 070621 9:27: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 193803648 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. 070621 9:27:32InnoDB: 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=0xa68d638 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 0xe8cde8 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 0xa6b5e68 = 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 070621 09:27:32 mysqld restarted 070621 9:27: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. 070621 9:27: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... 070621 9:27:32 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319564407. InnoDB: Doing recovery: scanned up to log sequence number 0 319564417 InnoDB: Last MySQL binlog file position 0 919, file name ./adflow-bin.000220 070621 9:27:32 InnoDB: Started; log sequence number 0 319564417 070621 9:27:32 [Note] Recovering after a crash using adflow-bin 070621 9:27:32 [Note] Starting crash recovery... 070621 9:27:32 [Note] Crash recovery finished. 070621 9:27: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 193803648 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. 070621 9:28:57InnoDB: 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=0xa794638 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 0xa7bce68 = 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 070621 09:28:57 mysqld restarted 070621 9:28:57 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070621 9:28: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... 070621 9:28:57 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319564427. InnoDB: Doing recovery: scanned up to log sequence number 0 319564427 InnoDB: Last MySQL binlog file position 0 919, file name ./adflow-bin.000220 070621 9:28:57 InnoDB: Started; log sequence number 0 319564427 070621 9:28:57 [Note] Recovering after a crash using adflow-bin 070621 9:28:57 [Note] Starting crash recovery... 070621 9:28:57 [Note] Crash recovery finished. 070621 9:28:58 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 193803648 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. 070621 9:29:28InnoDB: 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=0x9f96638 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 0x9fbee68 = 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 070621 09:29:28 mysqld restarted 070621 9:29:28 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070621 9:29:28 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070621 9:29:28 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319564427. InnoDB: Doing recovery: scanned up to log sequence number 0 319564437 InnoDB: Last MySQL binlog file position 0 919, file name ./adflow-bin.000220 070621 9:29:28 InnoDB: Started; log sequence number 0 319564437 070621 9:29:28 [Note] Recovering after a crash using adflow-bin 070621 9:29:28 [Note] Starting crash recovery... 070621 9:29:28 [Note] Crash recovery finished. 070621 9:29:29 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 193803648 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. 070621 9:29:49InnoDB: Assertion failure in thread 2539682736 in file fil0fil.c line 3959 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=402653184 read_buffer_size=2093056 max_used_connections=1 max_connections=100 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9450638 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=0x976059dc, 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 0xd78de8 0x8f493a 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 0x9478e68 = 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 070621 09:29:49 mysqld restarted 070621 9:29: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. 070621 9:29: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... 070621 9:29:50 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319564447. InnoDB: Doing recovery: scanned up to log sequence number 0 319564447 InnoDB: Last MySQL binlog file position 0 919, file name ./adflow-bin.000220 070621 9:29:50 InnoDB: Started; log sequence number 0 319564447 070621 9:29:50 [Note] Recovering after a crash using adflow-bin 070621 9:29:50 [Note] Starting crash recovery... 070621 9:29:50 [Note] Crash recovery finished. 070621 9:29: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 193803648 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. 070621 9:30:34InnoDB: 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=0x9509638 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 0x9531e68 = 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 070621 09:30:34 mysqld restarted 070621 9:30: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. 070621 9:30: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... 070621 9:30:34 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319564875. InnoDB: Doing recovery: scanned up to log sequence number 0 319564875 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000225 070621 9:30:34 InnoDB: Started; log sequence number 0 319564875 070621 9:30:34 [Note] Recovering after a crash using adflow-bin 070621 9:30:34 [Note] Starting crash recovery... 070621 9:30:34 [Note] Crash recovery finished. 070621 9:30: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 193803648 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. 070621 9:37:43InnoDB: Assertion failure in thread 2539662256 in file fil0fil.c line 3959 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=402653184 read_buffer_size=2093056 max_used_connections=10 max_connections=100 threads_connected=10 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=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=0x976009dc, 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 0xf3ede8 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 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 070621 09:37:44 mysqld restarted 070621 9:37: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. 070621 9:37:44 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... 070621 9:37:44 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319565688. InnoDB: Doing recovery: scanned up to log sequence number 0 319565688 InnoDB: Last MySQL binlog file position 0 646, file name ./adflow-bin.000226 070621 9:37:44 InnoDB: Started; log sequence number 0 319565688 070621 9:37:44 [Note] Recovering after a crash using adflow-bin 070621 9:37:44 [Note] Starting crash recovery... 070621 9:37:44 [Note] Crash recovery finished. 070621 9:37: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 193803648 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. 070621 9:37:51InnoDB: 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=0x99cd638 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 0x99f5e68 = 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 070621 09:37:51 mysqld restarted 070621 9:37: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. 070621 9:37: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... 070621 9:37:51 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319565688. InnoDB: Doing recovery: scanned up to log sequence number 0 319565698 InnoDB: Last MySQL binlog file position 0 646, file name ./adflow-bin.000226 070621 9:37:51 InnoDB: Started; log sequence number 0 319565698 070621 9:37:51 [Note] Recovering after a crash using adflow-bin 070621 9:37:51 [Note] Starting crash recovery... 070621 9:37:51 [Note] Crash recovery finished. 070621 9:37: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 193803648 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. 070621 9:38:06InnoDB: Assertion failure in thread 2539711408 in file fil0fil.c line 3959 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=402653184 read_buffer_size=2093056 max_used_connections=1 max_connections=100 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9e36638 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 0xce8de8 0x7e193a 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 0x9e5ee68 = 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 070621 09:38:06 mysqld restarted 070621 9:38: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. 070621 9:38: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... 070621 9:38:06 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319565708. InnoDB: Doing recovery: scanned up to log sequence number 0 319565708 InnoDB: Last MySQL binlog file position 0 646, file name ./adflow-bin.000226 070621 9:38:06 InnoDB: Started; log sequence number 0 319565708 070621 9:38:06 [Note] Recovering after a crash using adflow-bin 070621 9:38:06 [Note] Starting crash recovery... 070621 9:38:06 [Note] Crash recovery finished. 070621 9:38: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 193803648 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. 070621 9:38: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=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=0x9582638 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 0xc1dde8 0xd5793a 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 0x95aae68 = 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 070621 09:38:25 mysqld restarted 070621 9:38: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. 070621 9:38: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... 070621 9:38:25 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319566136. InnoDB: Doing recovery: scanned up to log sequence number 0 319566136 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000229 070621 9:38:25 InnoDB: Started; log sequence number 0 319566136 070621 9:38:25 [Note] Recovering after a crash using adflow-bin 070621 9:38:25 [Note] Starting crash recovery... 070621 9:38:25 [Note] Crash recovery finished. 070621 9:38: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 193803648 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. 070621 9:45:06InnoDB: Assertion failure in thread 2538711984 in file fil0fil.c line 3959 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=402653184 read_buffer_size=2093056 max_used_connections=10 max_connections=100 threads_connected=10 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8fdbb70 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=0x975189fc, 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 0x4a4de8 0xe1a93a 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 0x8fe7018 = 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=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 070621 09:45:06 mysqld restarted 070621 9:45: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. 070621 9:45: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... 070621 9:45:06 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319566564. InnoDB: Doing recovery: scanned up to log sequence number 0 319566564 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000230 070621 9:45:06 InnoDB: Started; log sequence number 0 319566564 070621 9:45:06 [Note] Recovering after a crash using adflow-bin 070621 9:45:06 [Note] Starting crash recovery... 070621 9:45:06 [Note] Crash recovery finished. 070621 9:45: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 66336128 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. 070621 10:02:28InnoDB: Assertion failure in thread 2538732464 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=21 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=0x96c7960 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=0x9751d9dc, 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 0x155de8 0x5a293a 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 0x96f4270 = 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=6 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 070621 10:02:28 mysqld restarted 070621 10:02:28 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070621 10:02:28 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070621 10:02:28 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319568477. InnoDB: Doing recovery: scanned up to log sequence number 0 319568477 InnoDB: Last MySQL binlog file position 0 1466, file name ./adflow-bin.000231 070621 10:02:28 InnoDB: Started; log sequence number 0 319568477 070621 10:02:28 [Note] Recovering after a crash using adflow-bin 070621 10:02:28 [Note] Starting crash recovery... 070621 10:02:28 [Note] Crash recovery finished. 070621 10:02:29 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 193803648 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. 070621 10:02:47InnoDB: 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=0xa5ca638 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 0x36fde8 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 0xa5f2e68 = 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 070621 10:02:47 mysqld restarted 070621 10:02:47 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070621 10:02:47 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070621 10:02:47 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319568487. InnoDB: Doing recovery: scanned up to log sequence number 0 319568487 InnoDB: Last MySQL binlog file position 0 1466, file name ./adflow-bin.000231 070621 10:02:47 InnoDB: Started; log sequence number 0 319568487 070621 10:02:47 [Note] Recovering after a crash using adflow-bin 070621 10:02:47 [Note] Starting crash recovery... 070621 10:02:47 [Note] Crash recovery finished. 070621 10:02: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 193803648 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. 070621 10:03:25InnoDB: Assertion failure in thread 2539330480 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=0x9f778b0 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=0x975af9dc, 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 0x9f82d58 = 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=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 070621 10:03:25 mysqld restarted 070621 10:03: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. 070621 10:03: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... 070621 10:03:26 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319568497. InnoDB: Doing recovery: scanned up to log sequence number 0 319568497 InnoDB: Last MySQL binlog file position 0 1466, file name ./adflow-bin.000231 070621 10:03:26 InnoDB: Started; log sequence number 0 319568497 070621 10:03:26 [Note] Recovering after a crash using adflow-bin 070621 10:03:26 [Note] Starting crash recovery... 070621 10:03:26 [Note] Crash recovery finished. 070621 10:03: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 193803648 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. 070621 10:03:36InnoDB: 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=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=0x8bf0768 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=0x975dd9fc, 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 0xe00de8 0x5b193a 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 0x8c05f58 = 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 070621 10:03:36 mysqld restarted 070621 10:03: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. 070621 10:03: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... 070621 10:03:36 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319568497. InnoDB: Doing recovery: scanned up to log sequence number 0 319568507 InnoDB: Last MySQL binlog file position 0 1466, file name ./adflow-bin.000231 070621 10:03:36 InnoDB: Started; log sequence number 0 319568507 070621 10:03:36 [Note] Recovering after a crash using adflow-bin 070621 10:03:36 [Note] Starting crash recovery... 070621 10:03:36 [Note] Crash recovery finished. 070621 10:03: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 193803648 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. 070621 10:03:46InnoDB: 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=0x8f30638 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 0xe9fde8 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 0x8f58e68 = 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 070621 10:03:46 mysqld restarted 070621 10:03:46 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070621 10:03: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... 070621 10:03:46 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319568507. InnoDB: Doing recovery: scanned up to log sequence number 0 319568517 InnoDB: Last MySQL binlog file position 0 1466, file name ./adflow-bin.000231 070621 10:03:46 InnoDB: Started; log sequence number 0 319568517 070621 10:03:46 [Note] Recovering after a crash using adflow-bin 070621 10:03:46 [Note] Starting crash recovery... 070621 10:03:46 [Note] Crash recovery finished. 070621 10:03: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 193803648 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. 070621 10:03:52InnoDB: 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=0x8f94638 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 0x69ede8 0x28893a 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 3010280368 stopped in file ut0mem.c line 230 thd->query at 0x8fbce68 = 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 070621 10:03:52 mysqld restarted 070621 10:03: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. 070621 10:03: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... 070621 10:03:53 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 319568517. InnoDB: Doing recovery: scanned up to log sequence number 0 319568527 InnoDB: Last MySQL binlog file position 0 1466, file name ./adflow-bin.000231 070621 10:03:53 InnoDB: Started; log sequence number 0 319568527 070621 10:03:53 [Note] Recovering after a crash using adflow-bin 070621 10:03:53 [Note] Starting crash recovery... 070621 10:03:53 [Note] Crash recovery finished. 070621 10:03: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 81016192 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. 070621 15:55:01InnoDB: 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=56 max_connections=100 threads_connected=55 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9284638 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 0x59ede8 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 0x92ace68 = 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 070621 15:55:01 mysqld restarted 070621 15:55: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. 070621 15:55: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... 070621 15:55:01 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320219183. InnoDB: Doing recovery: scanned up to log sequence number 0 320219183 InnoDB: Last MySQL binlog file position 0 622349, file name ./adflow-bin.000237 070621 15:55:01 InnoDB: Started; log sequence number 0 320219183 070621 15:55:01 [Note] Recovering after a crash using adflow-bin 070621 15:55:01 [Note] Starting crash recovery... 070621 15:55:01 [Note] Crash recovery finished. 070621 15:55: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 81016192 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. 070621 15:55:15InnoDB: 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=0xa1b3638 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... InnoDB: Thread 3010300848 stopped in file ut0mem.c line 230 thd->query at 0xa1dbe68 = 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 070621 15:55:15 mysqld restarted 070621 15:55: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. 070621 15:55: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... 070621 15:55:15 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320219183. InnoDB: Doing recovery: scanned up to log sequence number 0 320219193 InnoDB: Last MySQL binlog file position 0 622349, file name ./adflow-bin.000237 070621 15:55:15 InnoDB: Started; log sequence number 0 320219193 070621 15:55:15 [Note] Recovering after a crash using adflow-bin 070621 15:55:15 [Note] Starting crash recovery... 070621 15:55:15 [Note] Crash recovery finished. 070621 15:55: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 81016192 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. 070621 15:55:41InnoDB: Assertion failure in thread 2539711408 in file fil0fil.c line 3959 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=402653184 read_buffer_size=2093056 max_used_connections=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=0x9c87638 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 0x141de8 0x22993a 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 0x9cafe68 = 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 070621 15:55:41 mysqld restarted 070621 15:55:41 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070621 15:55:41 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070621 15:55:41 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320221478. InnoDB: Doing recovery: scanned up to log sequence number 0 320221478 InnoDB: Last MySQL binlog file position 0 963, file name ./adflow-bin.000239 070621 15:55:41 InnoDB: Started; log sequence number 0 320221478 070621 15:55:41 [Note] Recovering after a crash using adflow-bin 070621 15:55:41 [Note] Starting crash recovery... 070621 15:55:41 [Note] Crash recovery finished. 070621 15:55:42 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 81016192 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. 070621 15:55:47InnoDB: Assertion failure in thread 2539731888 in file fil0fil.c line 3959 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=402653184 read_buffer_size=2093056 max_used_connections=2 max_connections=100 threads_connected=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=0x9e6f638 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 0xf53de8 0x21593a 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 0x9e97e68 = 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 070621 15:55:47 mysqld restarted 070621 15:55:47 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070621 15:55:47 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070621 15:55:47 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320221478. InnoDB: Doing recovery: scanned up to log sequence number 0 320221488 InnoDB: Last MySQL binlog file position 0 963, file name ./adflow-bin.000239 070621 15:55:47 InnoDB: Started; log sequence number 0 320221488 070621 15:55:47 [Note] Recovering after a crash using adflow-bin 070621 15:55:47 [Note] Starting crash recovery... 070621 15:55:47 [Note] Crash recovery finished. 070621 15:55: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 81016192 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. 070621 15:56:08InnoDB: 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=0xa104638 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 0xb7ede8 0x2be93a 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 0xa12ce68 = 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 070621 15:56:08 mysqld restarted 070621 15:56: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. 070621 15:56:08 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... 070621 15:56:08 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320221498. InnoDB: Doing recovery: scanned up to log sequence number 0 320221498 InnoDB: Last MySQL binlog file position 0 963, file name ./adflow-bin.000239 070621 15:56:09 InnoDB: Started; log sequence number 0 320221498 070621 15:56:09 [Note] Recovering after a crash using adflow-bin 070621 15:56:09 [Note] Starting crash recovery... 070621 15:56:09 [Note] Crash recovery finished. 070621 15:56: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 81016192 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. 070621 15:57:16InnoDB: 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=0x9bb3638 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 0x9bdbe68 = 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 070621 15:57:16 mysqld restarted 070621 15:57: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. 070621 15:57: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... 070621 15:57:16 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320221508. InnoDB: Doing recovery: scanned up to log sequence number 0 320221508 InnoDB: Last MySQL binlog file position 0 963, file name ./adflow-bin.000239 070621 15:57:16 InnoDB: Started; log sequence number 0 320221508 070621 15:57:16 [Note] Recovering after a crash using adflow-bin 070621 15:57:16 [Note] Starting crash recovery... 070621 15:57:16 [Note] Crash recovery finished. 070621 15:57: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 193803648 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. 070621 15:57:25InnoDB: 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=0xa17f638 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x9760c9dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x115de8 0xe5093a 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 0xa1a7e68 = 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 070621 15:57:25 mysqld restarted 070621 15:57: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. 070621 15:57: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... 070621 15:57:26 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320221508. InnoDB: Doing recovery: scanned up to log sequence number 0 320221518 InnoDB: Last MySQL binlog file position 0 963, file name ./adflow-bin.000239 070621 15:57:26 InnoDB: Started; log sequence number 0 320221518 070621 15:57:26 [Note] Recovering after a crash using adflow-bin 070621 15:57:26 [Note] Starting crash recovery... 070621 15:57:26 [Note] Crash recovery finished. 070621 15:57: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 193803648 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. 070621 15:58: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=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=0x97a0638 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x976109dc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x817adf8 0x832532d 0x8303b8b 0x830397d 0x82facd4 0x82e9624 0x82bf7e1 0x82b5bc5 0x8227824 0x81d0e1d 0x81c2b0f 0x81c8ff1 0x81c2b1a 0x81c8cb3 0x81bdf76 0x81bf5c1 0x81bb382 0x818fa2a 0x8196a02 0x818e2a6 0x818ddcd 0x818d4c4 0x496de8 0xa2e93a 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 0x97c8e68 = 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 070621 15:58:16 mysqld restarted 070621 15:58: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. 070621 15:58: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... 070621 15:58:17 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320221528. InnoDB: Doing recovery: scanned up to log sequence number 0 320221528 InnoDB: Last MySQL binlog file position 0 963, file name ./adflow-bin.000239 070621 15:58:17 InnoDB: Started; log sequence number 0 320221528 070621 15:58:17 [Note] Recovering after a crash using adflow-bin 070621 15:58:17 [Note] Starting crash recovery... 070621 15:58:17 [Note] Crash recovery finished. 070621 15:58: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 180761984 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. 070621 19:00:48InnoDB: Assertion failure in thread 2539522992 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=33 max_connections=100 threads_connected=33 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 802415 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x958be88 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=0x975de9dc, 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 0x963b2a8 = 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 070621 19:00:48 mysqld restarted 070621 19:00: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. 070621 19:00: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... 070621 19:00:49 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320228840. InnoDB: Doing recovery: scanned up to log sequence number 0 320228840 InnoDB: Last MySQL binlog file position 0 5048, file name ./adflow-bin.000245 070621 19:00:49 InnoDB: Started; log sequence number 0 320228840 070621 19:00:49 [Note] Recovering after a crash using adflow-bin 070621 19:00:49 [Note] Starting crash recovery... 070621 19:00:49 [Note] Crash recovery finished. 070621 19:00: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 193803648 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. 070621 19:01:23InnoDB: Assertion failure in thread 2405493680 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=536870912 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 = 933487 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9ac9638 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=0x8f60c9dc, 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 0xcdcde8 0x60593a 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 0x9af1e68 = 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 070621 19:01:23 mysqld restarted 070621 19:01: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. 070621 19:01: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... 070621 19:01:23 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320228905. InnoDB: Doing recovery: scanned up to log sequence number 0 320228905 InnoDB: Last MySQL binlog file position 0 5048, file name ./adflow-bin.000245 070621 19:01:23 InnoDB: Started; log sequence number 0 320228905 070621 19:01:23 [Note] Recovering after a crash using adflow-bin 070621 19:01:23 [Note] Starting crash recovery... 070621 19:01:23 [Note] Crash recovery finished. 070621 19:01:23 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 193803648 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. 070621 19:02:13InnoDB: Assertion failure in thread 2405501872 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=536870912 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 = 933487 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8c41638 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=0x8f60e9dc, 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 0x8c69e68 = 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 070621 19:02:13 mysqld restarted 070621 19: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. 070621 19: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... 070621 19:02:13 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320228915. InnoDB: Doing recovery: scanned up to log sequence number 0 320228915 InnoDB: Last MySQL binlog file position 0 5048, file name ./adflow-bin.000245 070621 19:02:13 InnoDB: Started; log sequence number 0 320228915 070621 19:02:13 [Note] Recovering after a crash using adflow-bin 070621 19:02:13 [Note] Starting crash recovery... 070621 19:02:13 [Note] Crash recovery finished. 070621 19: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 193803648 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. 070621 19:02:32InnoDB: Assertion failure in thread 2405497776 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=536870912 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 = 933487 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x963e638 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=0x8f60d9fc, 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 0x1efde8 0x2d793a 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 0x9666e68 = 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 070621 19:02:32 mysqld restarted 070621 19:02: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. 070621 19:02: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... 070621 19:02:32 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320228915. InnoDB: Doing recovery: scanned up to log sequence number 0 320228925 InnoDB: Last MySQL binlog file position 0 5048, file name ./adflow-bin.000245 070621 19:02:32 InnoDB: Started; log sequence number 0 320228925 070621 19:02:32 [Note] Recovering after a crash using adflow-bin 070621 19:02:32 [Note] Starting crash recovery... 070621 19:02:32 [Note] Crash recovery finished. 070621 19:02:33 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 193803648 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. 070621 19:03:01InnoDB: Assertion failure in thread 2405501872 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=536870912 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 = 933487 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa0b6638 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=0x8f60e9dc, 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 0xa0dee68 = 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 070621 19:03:01 mysqld restarted 070621 19:03: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. 070621 19:03:02 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... 070621 19:03:02 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320228935. InnoDB: Doing recovery: scanned up to log sequence number 0 320228935 InnoDB: Last MySQL binlog file position 0 5048, file name ./adflow-bin.000245 070621 19:03:02 InnoDB: Started; log sequence number 0 320228935 070621 19:03:02 [Note] Recovering after a crash using adflow-bin 070621 19:03:02 [Note] Starting crash recovery... 070621 19:03:02 [Note] Crash recovery finished. 070621 19:03: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 193803648 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. 070621 19:03:52InnoDB: Assertion failure in thread 2405510064 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=536870912 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 = 933487 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9fa7638 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=0x8f6109fc, 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 0x234de8 0xb1f93a 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 0x9fcfe68 = 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 070621 19:03:53 mysqld restarted 070621 19:03: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. 070621 19:03: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... 070621 19:03:53 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320228935. InnoDB: Doing recovery: scanned up to log sequence number 0 320228945 InnoDB: Last MySQL binlog file position 0 5048, file name ./adflow-bin.000245 070621 19:03:53 InnoDB: Started; log sequence number 0 320228945 070621 19:03:53 [Note] Recovering after a crash using adflow-bin 070621 19:03:53 [Note] Starting crash recovery... 070621 19:03:53 [Note] Crash recovery finished. 070621 19:03: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 96220544 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. 070621 19:06:58InnoDB: Assertion failure in thread 2405497776 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=536870912 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 = 933487 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa060638 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=0x8f60d9fc, 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 0x72e93a 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 0xa088e68 = 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 070621 19:06:58 mysqld restarted 070621 19:06:58 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070621 19:06:58 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070621 19:06:58 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320228955. InnoDB: Doing recovery: scanned up to log sequence number 0 320228955 InnoDB: Last MySQL binlog file position 0 5048, file name ./adflow-bin.000245 070621 19:06:58 InnoDB: Started; log sequence number 0 320228955 070621 19:06:58 [Note] Recovering after a crash using adflow-bin 070621 19:06:58 [Note] Starting crash recovery... 070621 19:06:58 [Note] Crash recovery finished. 070621 19:06:59 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.0.27-standard-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL) InnoDB: Error: trying to access page number 193803648 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. 070621 19:07:13InnoDB: Assertion failure in thread 2405518256 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=536870912 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 = 933487 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa122638 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=0x8f6129fc, 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 0xbc0de8 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 3010313136 stopped in file ut0mem.c line 230 thd->query at 0xa14ae68 = 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 070621 19:07:13 mysqld restarted 070621 19:07: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. 070621 19:07: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... 070621 19:07:13 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320228955. InnoDB: Doing recovery: scanned up to log sequence number 0 320228965 InnoDB: Last MySQL binlog file position 0 5048, file name ./adflow-bin.000245 070621 19:07:13 InnoDB: Started; log sequence number 0 320228965 070621 19:07:14 [Note] Recovering after a crash using adflow-bin 070621 19:07:14 [Note] Starting crash recovery... 070621 19:07:14 [Note] Crash recovery finished. 070621 19:07: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 193803648 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. 070621 19:08:48InnoDB: Assertion failure in thread 2405510064 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=536870912 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 = 933487 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8d6c638 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=0x8f6109dc, 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 0x292de8 0x4c893a 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 0x8d94e68 = 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 070621 19:08:48 mysqld restarted 070621 19:08: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. 070621 19:08: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... 070621 19:08:48 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320228975. InnoDB: Doing recovery: scanned up to log sequence number 0 320228975 InnoDB: Last MySQL binlog file position 0 5048, file name ./adflow-bin.000245 070621 19:08:48 InnoDB: Started; log sequence number 0 320228975 070621 19:08:48 [Note] Recovering after a crash using adflow-bin 070621 19:08:48 [Note] Starting crash recovery... 070621 19:08:48 [Note] Crash recovery finished. 070621 19:08: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 193803648 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. 070621 19:15:01InnoDB: Assertion failure in thread 2405501872 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=536870912 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 = 933487 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa644638 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=0x8f60e9fc, 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 0xa66ce68 = 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 070621 19:15:01 mysqld restarted 070621 19:15: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. 070621 19:15: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... 070621 19:15:01 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320228975. InnoDB: Doing recovery: scanned up to log sequence number 0 320228985 InnoDB: Last MySQL binlog file position 0 5048, file name ./adflow-bin.000245 070621 19:15:01 InnoDB: Started; log sequence number 0 320228985 070621 19:15:01 [Note] Recovering after a crash using adflow-bin 070621 19:15:01 [Note] Starting crash recovery... 070621 19:15:01 [Note] Crash recovery finished. 070621 19:15: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 193803648 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. 070621 19:16:51InnoDB: Assertion failure in thread 2405309360 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=536870912 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 = 933487 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x91d5140 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=0x8f5df9fc, 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 0x91f1588 = 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 070621 19:16:51 mysqld restarted 070621 19:16: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. 070621 19:16: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... 070621 19:16:51 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320229414. InnoDB: Doing recovery: scanned up to log sequence number 0 320229414 InnoDB: Last MySQL binlog file position 0 371, file name ./adflow-bin.000255 070621 19:16:51 InnoDB: Started; log sequence number 0 320229414 070621 19:16:51 [Note] Recovering after a crash using adflow-bin 070621 19:16:51 [Note] Starting crash recovery... 070621 19:16:51 [Note] Crash recovery finished. 070621 19:16: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 79181184 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. 070621 19:26:08InnoDB: Assertion failure in thread 2405120944 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=536870912 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 = 933487 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x9a275b8 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=0x8f5b19dc, 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 0x681de8 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 0x9a39020 = 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=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 070621 19:26:08 mysqld restarted 070621 19:26: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. 070621 19: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... 070621 19:26:09 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320229826. InnoDB: Doing recovery: scanned up to log sequence number 0 320229826 InnoDB: Last MySQL binlog file position 0 372, file name ./adflow-bin.000256 070621 19:26:09 InnoDB: Started; log sequence number 0 320229826 070621 19:26:09 [Note] Recovering after a crash using adflow-bin 070621 19:26:09 [Note] Starting crash recovery... 070621 19:26:09 [Note] Crash recovery finished. 070621 19: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 79181184 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. 070621 19:26:14InnoDB: Assertion failure in thread 2405514160 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=536870912 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 = 933487 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa5e1638 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=0x8f6119dc, 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 0xa17de8 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 3010309040 stopped in file sync0arr.c line 336 thd->query at 0xa609e68 = 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 070621 19:26:14 mysqld restarted 070621 19:26:14 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070621 19:26:14 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070621 19:26:14 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320229826. InnoDB: Doing recovery: scanned up to log sequence number 0 320229836 InnoDB: Last MySQL binlog file position 0 372, file name ./adflow-bin.000256 070621 19:26:14 InnoDB: Started; log sequence number 0 320229836 070621 19:26:14 [Note] Recovering after a crash using adflow-bin 070621 19:26:14 [Note] Starting crash recovery... 070621 19:26:14 [Note] Crash recovery finished. 070621 19:26: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 193803648 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. 070621 19:26:22InnoDB: Assertion failure in thread 2405501872 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=536870912 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 = 933487 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8b7b638 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=0x8f60e9dc, 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 0x8ba3e68 = 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 070621 19:26:22 mysqld restarted 070621 19:26:22 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=adflow-bin' to avoid this problem. 070621 19:26:22 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 070621 19:26:22 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 320229836. InnoDB: Doing recovery: scanned up to log sequence number 0 320229846 InnoDB: Last MySQL binlog file position 0 372, file name ./adflow-bin.000256 070621 19:26:22 InnoDB: Started; log sequence number 0 320229846 070621 19:26:22 [Note] Recovering after a crash using adflow-bin 070621 19:26:22 [Note] Starting crash recovery... 070621 19:26:22 [Note] Crash recovery finished. 070621 19:26: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)