080125 10:56:29 mysqld started 080125 10:56:30 InnoDB: Started; log sequence number 5 1573000639 080125 10:56:30 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.0.45' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution 080129 10:33:20 - mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary 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=10485760 read_buffer_size=131072 max_used_connections=15 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 = 227839 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xb038810 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x68446c78, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8188be3 0x827c7d4 0x827def2 0x827e008 0x827e09a 0x827e266 0x827e38d 0x8203ee7 0x81a069a 0x81a3fe0 0x81a45c3 0x81a5a17 0x81a65e7 0x2cc50b 0x51cb2e 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 0x65ba8c48 is invalid pointer thd->thread_id=100092 The 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 080129 10:33:21 mysqld restarted 080129 10:33: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... 080129 10:33:22 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 5 2310800062. InnoDB: Doing recovery: scanned up to log sequence number 5 2312148364 InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 7566 row operations to undo InnoDB: Trx id counter is 0 29159936 080129 10:33:22 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Starting in background the rollback of uncommitted transactions 080129 10:33:27 InnoDB: Rolling back trx with id 0 29159515, 7566 rows to undo InnoDB: Progress in percents: 1080129 10:33:27 InnoDB: Started; log sequence number 5 2312148364 080129 10:33:27 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.0.45' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 InnoDB: Rolling back of trx id 0 29159515 completed 080129 10:33:27 InnoDB: Rollback of non-prepared transactions completed 080201 9:00:34 - mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary 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=10485760 read_buffer_size=131072 max_used_connections=28 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 = 227839 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x65c82f38 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x6816aca8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8188be3 0x2cfcef 0x827e09a 0x827e266 0x827e38d 0x8203ee7 0x81a069a 0x81a3fe0 0x81a45c3 0x81a5a17 0x81a65e7 0x2cc50b 0x51cb2e 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 0x6804a030 is invalid pointer thd->thread_id=109958 The 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 080201 09:00:34 mysqld restarted 080201 9:00:35 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 080201 9:00:35 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 5 3145733715. InnoDB: Doing recovery: scanned up to log sequence number 5 3147041298 InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 7336 row operations to undo InnoDB: Trx id counter is 0 30890752 080201 9:00:35 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Starting in background the rollback of uncommitted transactions 080201 9:00:41 InnoDB: Rolling back trx with id 0 30890274, 7336 rows to undo InnoDB: Progress in percents: 1080201 9:00:41 InnoDB: Started; log sequence number 5 3147041298 2 3 4 5 6 7 8 9 10 11 12 13 14080201 9:00:41 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.0.45' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 InnoDB: Rolling back of trx id 0 30890274 completed 080201 9:00:41 InnoDB: Rollback of non-prepared transactions completed 080202 8:02:27 - mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary 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=10485760 read_buffer_size=131072 max_used_connections=15 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 = 227839 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xb0512d8 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x68283cb8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8188be3 0x827dfea 0x827e09a 0x827e266 0x827e38d 0x8203ee7 0x81a069a 0x81a3fe0 0x81a45c3 0x81a5a17 0x81a65e7 0x2cc50b 0x51cb2e 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 0x6811d158 is invalid pointer thd->thread_id=31589 The 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 080202 08:02:28 mysqld restarted 080202 8: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... 080202 8:02:29 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 5 3423372410. InnoDB: Doing recovery: scanned up to log sequence number 5 3424740891 InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 7583 row operations to undo InnoDB: Trx id counter is 0 31622144 080202 8:02:29 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Starting in background the rollback of uncommitted transactions 080202 8:02:34 InnoDB: Rolling back trx with id 0 31621650, 7583 rows to undo InnoDB: Progress in percents: 1080202 8:02:34 InnoDB: Started; log sequence number 5 3424740891 2 3 4 5 6 7 8 9 10 11 12 13 14080202 8:02:34 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.0.45' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 InnoDB: Rolling back of trx id 0 31621650 completed 080202 8:02:34 InnoDB: Rollback of non-prepared transactions completed 080202 10:52:38 - mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary 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=10485760 read_buffer_size=131072 max_used_connections=4 max_connections=100 threads_connected=3 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 227839 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x65c0c810 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x65d7fc78, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8188be3 0x827c7d4 0x827def2 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 0x65c18280 is invalid pointer thd->thread_id=3822 The 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 080202 10:52:38 mysqld restarted 080202 10:52: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... 080202 10:52:39 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 5 3466749362. InnoDB: Doing recovery: scanned up to log sequence number 5 3466755712 080202 10:52:39 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed 080202 10:52:40 InnoDB: Started; log sequence number 5 3466755712 080202 10:52:40 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.0.45' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution 080202 17:19:06 - mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary 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=10485760 read_buffer_size=131072 max_used_connections=6 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 = 227839 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xb90b3a0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x65cacd28, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8188be3 0x827c7d4 0x827def2 0x827e008 0x827e09a 0x827e266 0x827e38d 0x82003a2 0x81a0751 0x81a3fe0 0x81a45c3 0x81a5a17 0x81a65e7 0x2cc50b 0x51cb2e 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 0xba86a90 = UPDATE vsm_sklad SET f_quantity='4' WHERE f_store_id=24247 thd->thread_id=9357 The 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 080202 17:19:06 mysqld restarted 080202 17:19: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... 080202 17:19:06 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 5 3555985605. InnoDB: Doing recovery: scanned up to log sequence number 5 3555990602 080202 17:19:07 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed 080202 17:19:07 InnoDB: Started; log sequence number 5 3555990602 080202 17:19:07 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.0.45' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution 080205 8:01:45 - mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary 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=10485760 read_buffer_size=131072 max_used_connections=41 max_connections=40 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 97279 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xc15fe30 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x67d8bcb8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8188be3 0x827dfea 0x827e09a 0x827e266 0x827e38d 0x8203ee7 0x81a069a 0x81a3fe0 0x81a45c3 0x81a5a17 0x81a65e7 0x5c850b 0x4b8b2e 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 0xbfc0720 = DELETE FROM vsm_sklad WHERE f_provider_id='16' thd->thread_id=33342 The 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 080205 08:01:45 mysqld restarted 080205 8:01:46 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 080205 8:01:46 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 6 2389134393. InnoDB: Doing recovery: scanned up to log sequence number 6 2390501604 InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 7695 row operations to undo InnoDB: Trx id counter is 0 37068544 080205 8:01:46 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Starting in background the rollback of uncommitted transactions 080205 8:01:50 InnoDB: Rolling back trx with id 0 37068257, 7695 rows to undo InnoDB: Progress in percents: 1080205 8:01:50 InnoDB: Started; log sequence number 6 2390501604 2 3 4 5 6 7 8 9 10 11 12080205 8:01:50 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.0.45' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 InnoDB: Rolling back of trx id 0 37068257 completed 080205 8:01:51 InnoDB: Rollback of non-prepared transactions completed 080205 8:11:28 - mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary 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=10485760 read_buffer_size=131072 max_used_connections=3 max_connections=40 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 97279 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xbe4e668 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x65d9fc78, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8188be3 0x827c7d4 0x827def2 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 0xbe3a8b0 = DELETE FROM vsm_sklad WHERE f_provider_id='16' thd->thread_id=120 The 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 080205 08:11:29 mysqld restarted 080205 8:11:29 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 080205 8:11:29 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 6 2391412342. InnoDB: Doing recovery: scanned up to log sequence number 6 2392532900 InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 6740 row operations to undo InnoDB: Trx id counter is 0 37072128 080205 8:11:29 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Starting in background the rollback of uncommitted transactions 080205 8:11:33 InnoDB: Rolling back trx with id 0 37071627, 6740 rows to undo InnoDB: Progress in percents: 1080205 8:11:33 InnoDB: Started; log sequence number 6 2392532900 2 3080205 8:11:33 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.0.45' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 InnoDB: Rolling back of trx id 0 37071627 completed 080205 8:11:34 InnoDB: Rollback of non-prepared transactions completed 080205 14:45:08 - mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary 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=10485760 read_buffer_size=131072 max_used_connections=15 max_connections=40 threads_connected=2 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 97279 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x65b1c6d8 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x68531cb8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8188be3 0x827dfea 0x827e09a 0x827e266 0x827e38d 0x8203ee7 0x81a069a 0x81a3fe0 0x81a45c3 0x81a5a17 0x81a65e7 0x5c850b 0x4b8b2e 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 0xc609b70 = DELETE FROM vsm_sklad WHERE f_store_id=14046 thd->thread_id=19429 The 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 080205 14:45:08 mysqld restarted 080205 14:45: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... 080205 14:45:09 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 6 2512882310. InnoDB: Doing recovery: scanned up to log sequence number 6 2512904947 080205 14:45:09 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed 080205 14:45:10 InnoDB: Started; log sequence number 6 2512904947 080205 14:45:10 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.0.45' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution