030724 08:07:16 mysqld started /usr/local/mysql/libexec/mysqld: ready for connections. Version: '4.0.13-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=268435456 read_buffer_size=2093056 sort_buffer_size=2097144 max_used_connections=17 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 = 671343 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x84319d0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbefff088, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80f1528 0x40156d29 0x816d910 0x816d33a 0x816b29e 0x81024f2 0x8100269 0x8101431 0x80fc4b5 0x80fc034 0x80fb9a9 0x40151a19 0x4038a437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x83da158 = FLUSH QUERY CACHE thd->thread_id=8184 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 8184 did to cause the crash. In some cases of really bad corruption, the values shown above may be invalid. The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 0 030724 15:40:01 mysqld restarted /usr/local/mysql/libexec/mysqld: ready for connections. Version: '4.0.13-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=268435456 read_buffer_size=2093056 sort_buffer_size=2097144 max_used_connections=12 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 = 671343 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x84cfce0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbedfedc8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80f1528 0x40156d29 0x40155eb6 0x816ace7 0x81269f2 0x80fdf53 0x8101431 0x80fc4b5 0x80fc034 0x80fb9a9 0x40151a19 0x4038a437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x84dda00 = INSERT INTO pages (doktype,hidden,starttime,endtime,layout,urltype,lastUpdated,newUntil,cache_timeout,shortcut_mode,module,perms_userid,perms_groupid,perms_user,perms_group,perms_everybody,sorting,pid,no_search,alias,target,no_cache,subtitle,TSconfig,storage_pid,is_siteroot,fe_group,extendToSubpages,crdate,cruser_id,tstamp) VALUES ('254','0','0','0','0','1','0','0','0','0','','2','0','31','27','0','32','83','0','','','0','','','','0','','0','1059058163','2','1059058163') thd->thread_id=1195 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 1195 did to cause the crash. In some cases of really bad corruption, the values shown above may be invalid. The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 0 030724 16:42:24 mysqld restarted /usr/local/mysql/libexec/mysqld: ready for connections. Version: '4.0.13-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=268435456 read_buffer_size=2093056 sort_buffer_size=2097144 max_used_connections=15 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 = 671343 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x584150d8 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbe3ff088, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80f1528 0x40156d29 0x816d910 0x816d33a 0x816b29e 0x81024f2 0x8100269 0x8101431 0x80fc4b5 0x80fc034 0x80fb9a9 0x40151a19 0x4038a437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x584159a0 is invalid pointer thd->thread_id=6970 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 6970 did to cause the crash. In some cases of really bad corruption, the values shown above may be invalid. The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 0 030725 08:20:01 mysqld restarted /usr/local/mysql/libexec/mysqld: ready for connections. Version: '4.0.13-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=268435456 read_buffer_size=2093056 sort_buffer_size=2097144 max_used_connections=22 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 = 671343 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x85968f0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbd9ff088, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80f1528 0x40156d29 0x816d910 0x816d33a 0x816b29e 0x81024f2 0x8100269 0x8101431 0x80fc4b5 0x80fc034 0x80fb9a9 0x40151a19 0x4038a437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x85d8b00 = FLUSH QUERY CACHE thd->thread_id=5007 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 5007 did to cause the crash. In some cases of really bad corruption, the values shown above may be invalid. The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 0 030725 13:40:01 mysqld restarted /usr/local/mysql/libexec/mysqld: ready for connections. Version: '4.0.13-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=268435456 read_buffer_size=2093056 sort_buffer_size=2097144 max_used_connections=13 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 = 671343 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x58514398 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbe3fecb8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80f1528 0x40156d29 0x827ff13 0x827f8fe 0x816b9bb 0x816acf2 0x812a29c 0x80fde7c 0x8101431 0x80fc4b5 0x80fc034 0x80fb9a9 0x40151a19 0x4038a437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x8444a10 = UPDATE bb1_boards SET posts=posts+1, lastposttime = '1059258875', lastpostid = '75994' WHERE boardid = '8' thd->thread_id=14360 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 14360 did to cause the crash. In some cases of really bad corruption, the values shown above may be invalid. The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 0 030727 00:34:40 mysqld restarted /usr/local/mysql/libexec/mysqld: ready for connections. Version: '4.0.13-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=268435456 read_buffer_size=2093056 sort_buffer_size=2097144 max_used_connections=5 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 = 671343 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x83b1e30 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbefff088, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80f1528 0x40156d29 0x816d910 0x816d33a 0x816b29e 0x81024f2 0x8100269 0x8101431 0x80fc4b5 0x80fc034 0x80fb9a9 0x40151a19 0x4038a437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x58530ed0 is invalid pointer thd->thread_id=12164 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 12164 did to cause the crash. In some cases of really bad corruption, the values shown above may be invalid. The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 0 030728 00:20:01 mysqld restarted /usr/local/mysql/libexec/mysqld: ready for connections. Version: '4.0.13-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=268435456 read_buffer_size=2093056 sort_buffer_size=2097144 max_used_connections=22 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 = 671343 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x84fb738 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbefff0f8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80f1528 0x40156d29 0x827ff13 0x827f574 0x816a675 0x80fd33b 0x8101431 0x80fc4b5 0x80fc034 0x80fb9a9 0x40151a19 0x4038a437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x8473b48 = SELECT content FROM cache_hash WHERE hash='4c36573bb185de3db4ecdeac13b2af40' thd->thread_id=3597 Successfully dumped variables, if you ran with --log, take a look at the details of what thread 3597 did to cause the crash. In some cases of really bad corruption, the values shown above may be invalid. The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 0 030728 11:01:10 mysqld restarted /usr/local/mysql/libexec/mysqld: ready for connections. Version: '4.0.13-log' socket: '/tmp/mysql.sock' port: 3306 030729 7:20:49 /usr/local/mysql/libexec/mysqld: Normal shutdown 030729 7:20:50 /usr/local/mysql/libexec/mysqld: Shutdown Complete 030729 07:20:50 mysqld ended 030729 07:24:52 mysqld started /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.0.14-max-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=268435456 read_buffer_size=2093056 max_used_connections=15 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 = 671343 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x58728568 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbdbfeee8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d9a90 0x4003ad29 0x40039eb6 0x8151be5 0x8151ba2 0x8151b6b 0x8151aee 0x8150d1e 0x8110928 0x80e5824 0x80e7fba 0x80e3483 0x80e2edd 0x80e26ce 0x40035a19 0x401bf437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x8650428 = UPDATE pages SET SYS_LASTCHANGED=1059465634 WHERE uid='159' thd->thread_id=1594 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 2 030729 10:00:37 mysqld restarted /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.0.14-max-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=268435456 read_buffer_size=2093056 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 = 671343 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x858dc90 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbe3feef8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d9a90 0x4003ad29 0x835b933 0x835be95 0x815167f 0x8151bf2 0x8151ba2 0x8151b6b 0x8151aee 0x8150d1e 0x8112413 0x80e5e1d 0x80e7fba 0x80e3483 0x80e2edd 0x80e26ce 0x40035a19 0x401bf437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x58570080 is invalid pointer thd->thread_id=10748 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 2 030730 02:21:10 mysqld restarted /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.0.14-max-log' socket: '/tmp/mysql.sock' port: 3306 030730 9:48:40 Note: Found 0 of 10 rows when repairing './sturmdb/bb1_useronline' mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=268435456 read_buffer_size=2093056 max_used_connections=43 max_connections=100 threads_connected=19 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 671343 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x58438e88 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbc3ff2e8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d9a90 0x4003ad29 0x835b788 0x835ba7b 0x815088f 0x80e4384 0x80e7fba 0x80e3483 0x80e2edd 0x80e26ce 0x40035a19 0x401bf437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x8528818 = SELECT pages.uid, sys_domain.redirectTo,sys_domain.prepend_params FROM pages,sys_domain WHERE pages.uid=sys_domain.pid AND NOT sys_domain.hidden AND (sys_domain.domainName='www.sk-sturm.at' or sys_domain.domainName='www.sk-sturm.at/') AND NOT pages.deleted AND NOT pages.hidden AND (pages.starttime<=1059594886) AND (pages.endtime=0 OR pages.endtime>1059594886) AND doktype<200 AND fe_group IN (0,-1) LIMIT 1 thd->thread_id=29615 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 4 030730 21:54:47 mysqld restarted /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.0.14-max-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=268435456 read_buffer_size=2093056 max_used_connections=32 max_connections=100 threads_connected=12 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 671343 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x5831e0c0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbd3ff268, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d9a90 0x4003ad29 0x8152813 0x81525bb 0x8150fe9 0x80e91bd 0x80e71f2 0x80e7fba 0x80e3483 0x80e2edd 0x80e26ce 0x40035a19 0x401bf437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x8583570 = FLUSH QUERY CACHE thd->thread_id=9663 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 2 030731 02:20:01 mysqld restarted /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.0.14-max-log' socket: '/tmp/mysql.sock' port: 3306 030731 9:53:09 /usr/local/mysql/bin/mysqld: Normal shutdown 030731 9:53:10 /usr/local/mysql/bin/mysqld: Shutdown Complete 030731 09:53:10 mysqld ended 030731 09:53:13 mysqld started /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.0.14-max-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=402653184 read_buffer_size=2093056 max_used_connections=66 max_connections=100 threads_connected=29 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=0x5a502e90 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbc3ff268, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d9a90 0x4003ad29 0x8152813 0x81525bb 0x8150fe9 0x80e91bd 0x80e71f2 0x80e7fba 0x80e3483 0x80e2edd 0x80e26ce 0x40035a19 0x401bf437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x860f1e0 = FLUSH QUERY CACHE thd->thread_id=56037 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 2 030731 17:40:01 mysqld restarted /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.0.14-max-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=402653184 read_buffer_size=2093056 max_used_connections=51 max_connections=100 threads_connected=28 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=0x5a3b9ba0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbddff268, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d9a90 0x4003ad29 0x8152813 0x81525bb 0x8150fe9 0x80e91bd 0x80e71f2 0x80e7fba 0x80e3483 0x80e2edd 0x80e26ce 0x40035a19 0x401bf437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x86350c0 = FLUSH QUERY CACHE thd->thread_id=4372 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 2 030731 18:20:01 mysqld restarted /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.0.14-max-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info 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=48 max_connections=100 threads_connected=39 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=0x5a375520 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbe9ff268, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d9a90 0x4003ad29 0x8152813 0x81525bb 0x8150fe9 0x80e91bd 0x80e71f2 0x80e7fba 0x80e3483 0x80e2edd 0x80e26ce 0x40035a19 0x401bf437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x85dfb30 = FLUSH QUERY CACHE thd->thread_id=4980 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 2 030731 19:20:01 mysqld restarted /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.0.14-max-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info 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=43 max_connections=100 threads_connected=19 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=0x5a311e78 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbbdff268, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d9a90 0x4003ad29 0x8152813 0x81525bb 0x8150fe9 0x80e91bd 0x80e71f2 0x80e7fba 0x80e3483 0x80e2edd 0x80e26ce 0x40035a19 0x401bf437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x8590ed0 = FLUSH QUERY CACHE thd->thread_id=3455 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 2 030731 20:00:01 mysqld restarted /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.0.14-max-log' socket: '/tmp/mysql.sock' port: 3306 030801 7:41:15 /usr/local/mysql/bin/mysqld: Normal shutdown 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17216 user: 'root' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17156 user: 'root' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17151 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17150 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17149 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17148 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17147 user: 'web' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17146 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17145 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17144 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17143 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17142 user: 'web' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17141 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17140 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17139 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17138 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17137 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17136 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17135 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17134 user: 'web' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17133 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17132 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17131 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17130 user: 'web' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17129 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17128 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17127 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17126 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17125 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17124 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17123 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17122 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17121 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17120 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17119 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17118 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17117 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17116 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17115 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17114 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17113 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17111 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17110 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17109 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17108 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17107 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17106 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17105 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17104 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17103 user: 'web' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17102 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17101 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17100 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17099 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17098 user: 'web' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17097 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17096 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17095 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17094 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17093 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17092 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17091 user: 'web' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17090 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17089 user: 'web' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17088 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17087 user: 'web' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17086 user: 'web' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17085 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17084 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17083 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17082 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17081 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17080 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17079 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17078 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17077 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17076 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17075 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17074 user: 'typo3' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17073 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17072 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17071 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17070 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17069 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17068 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17067 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17066 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17065 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17064 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17063 user: 'sturm' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 17062 user: 'root' 030801 7:41:16 /usr/local/mysql/bin/mysqld: Forcing close of thread 16945 user: 'typo3' 030801 07:44:39 mysqld started /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.0.14-max-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info 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=47 max_connections=300 threads_connected=28 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1620813 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x5a733020 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbebff268, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d9a90 0x4003ad29 0x8152813 0x81525bb 0x8150fe9 0x80e91bd 0x80e71f2 0x80e7fba 0x80e3483 0x80e2edd 0x80e26ce 0x40035a19 0x401bf437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x861f4c8 = FLUSH QUERY CACHE thd->thread_id=13613 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 2 030801 14:20:01 mysqld restarted /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.0.14-max-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info 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=37 max_connections=300 threads_connected=20 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1620813 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x5a37bb28 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbf5ff268, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d9a90 0x4003ad29 0x8152813 0x81525bb 0x8150fe9 0x80e91bd 0x80e71f2 0x80e7fba 0x80e3483 0x80e2edd 0x80e26ce 0x40035a19 0x401bf437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x8625b00 = FLUSH QUERY CACHE thd->thread_id=5437 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 2 030801 18:20:01 mysqld restarted /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.0.14-max-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=402653184 read_buffer_size=2093056 max_used_connections=31 max_connections=300 threads_connected=10 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1620813 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x5a508df0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbdfff268, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d9a90 0x4003ad29 0x8152813 0x81525bb 0x8150fe9 0x80e91bd 0x80e71f2 0x80e7fba 0x80e3483 0x80e2edd 0x80e26ce 0x40035a19 0x401bf437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x8628d08 = FLUSH QUERY CACHE thd->thread_id=5952 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 2 030802 01:20:01 mysqld restarted /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.0.14-max-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info 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=26 max_connections=300 threads_connected=8 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1620813 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x5a50ce00 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbefff268, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d9a90 0x4003ad29 0x8152813 0x81525bb 0x8150fe9 0x80e91bd 0x80e71f2 0x80e7fba 0x80e3483 0x80e2edd 0x80e26ce 0x40035a19 0x401bf437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x84d8b70 = FLUSH QUERY CACHE thd->thread_id=6026 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 2 030802 16:20:01 mysqld restarted /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.0.14-max-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info 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=32 max_connections=300 threads_connected=11 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1620813 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x5a32ad78 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbf1ff268, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d9a90 0x4003ad29 0x8152813 0x81525bb 0x8150fe9 0x80e91bd 0x80e71f2 0x80e7fba 0x80e3483 0x80e2edd 0x80e26ce 0x40035a19 0x401bf437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x85bb650 = FLUSH QUERY CACHE thd->thread_id=17419 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 2 030804 00:20:01 mysqld restarted /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.0.14-max-log' socket: '/tmp/mysql.sock' port: 3306 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=402653184 read_buffer_size=2093056 max_used_connections=24 max_connections=300 threads_connected=19 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1620813 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x86131e0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xbf1ff268, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80d9a90 0x4003ad29 0x8152813 0x81525bb 0x8150fe9 0x80e91bd 0x80e71f2 0x80e7fba 0x80e3483 0x80e2edd 0x80e26ce 0x40035a19 0x401bf437 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in 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 0x5a668070 is invalid pointer thd->thread_id=2031 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 4 030804 08:20:01 mysqld restarted /usr/local/mysql/bin/mysqld: ready for connections. Version: '4.0.14-max-log' socket: '/tmp/mysql.sock' port: 3306