060619 19:33:51 mysqld started 060619 19:33:52 InnoDB: Started; log sequence number 0 43655 060619 19:33:52 [Note] /home/sbester/servers/5.0-bk/bin/mysqld: ready for connections. Version: '5.0.23-debug' socket: '/tmp/my.sock' port: 3306 yes mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=8388572 read_buffer_size=131072 max_used_connections=46 max_connections=200 threads_connected=44 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 443384 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xb7c450c8 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x8fd5cc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80daa23 handle_segfault + 461 0xb9e420 data.7108 + 12182516 0xa2b03d0 __stop___libc_freeres_ptrs + 29488880 0x80f1fc0 _Z21mysql_execute_commandP3THD + 11044 0x820b6d5 _ZN13sp_instr_stmt9exec_coreEP3THDPj + 17 0x820c0e1 _ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr + 363 0x8210dca _ZN13sp_instr_stmt7executeEP3THDPj + 1602 0x820ef9c _ZN7sp_head7executeEP3THD + 1096 0x820f87d _ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE + 1183 0x80f4ea9 _Z21mysql_execute_commandP3THD + 23053 0x80f7326 _Z11mysql_parseP3THDPcj + 330 0x80f7ccb _Z16dispatch_command19enum_server_commandP3THDPcj + 2157 0x80f8f3d _Z10do_commandP3THD + 537 0x80f9d02 handle_one_connection + 3350 0x83c1d56 start_thread + 98 0x841993e __clone + 110 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 0xa2b7e58 = DELETE from g1 using g2,g1 where g2.id1=g1.id1 thd->thread_id=3510 The manual page at http://www.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 060619 19:35:46 mysqld restarted 060619 19:35: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... 060619 19:35:46 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 43665. InnoDB: Doing recovery: scanned up to log sequence number 0 43665 060619 19:35:46 InnoDB: Started; log sequence number 0 43665 060619 19:35:46 [Note] /home/sbester/servers/5.0-bk/bin/mysqld: ready for connections. Version: '5.0.23-debug' socket: '/tmp/my.sock' port: 3306 yes mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=8388572 read_buffer_size=131072 max_used_connections=42 max_connections=200 threads_connected=39 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 443384 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xb7ed87a8 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x1f5a5cc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80daa23 handle_segfault + 461 0x1f3420 data.7108 + 2044916 0x941a678 __stop___libc_freeres_ptrs + 14195096 0x80f1fc0 _Z21mysql_execute_commandP3THD + 11044 0x820b6d5 _ZN13sp_instr_stmt9exec_coreEP3THDPj + 17 0x820c0e1 _ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr + 363 0x8210dca _ZN13sp_instr_stmt7executeEP3THDPj + 1602 0x820ef9c _ZN7sp_head7executeEP3THD + 1096 0x820f87d _ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE + 1183 0x80f4ea9 _Z21mysql_execute_commandP3THD + 23053 0x80f7326 _Z11mysql_parseP3THDPcj + 330 0x80f7ccb _Z16dispatch_command19enum_server_commandP3THDPcj + 2157 0x80f8f3d _Z10do_commandP3THD + 537 0x80f9d02 handle_one_connection + 3350 0x83c1d56 start_thread + 98 0x841993e __clone + 110 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 0x9433b18 = DELETE from g1 using g2,g1 where g2.id1=g1.id1 thd->thread_id=3686 The manual page at http://www.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 060619 19:38:35 mysqld restarted 060619 19:38: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... 060619 19:38:35 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 43665. InnoDB: Doing recovery: scanned up to log sequence number 0 43665 060619 19:38:35 InnoDB: Started; log sequence number 0 43665 060619 19:38:35 [Note] /home/sbester/servers/5.0-bk/bin/mysqld: ready for connections. Version: '5.0.23-debug' socket: '/tmp/my.sock' port: 3306 yes mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=8388572 read_buffer_size=131072 max_used_connections=42 max_connections=200 threads_connected=42 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 443384 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xb7ea5d28 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xd995cc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80daa23 handle_segfault + 461 0xd0b420 data.7108 + 13677556 0xa781d68 __stop___libc_freeres_ptrs + 34541704 0x80f1fc0 _Z21mysql_execute_commandP3THD + 11044 0x820b6d5 _ZN13sp_instr_stmt9exec_coreEP3THDPj + 17 0x820c0e1 _ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr + 363 0x8210dca _ZN13sp_instr_stmt7executeEP3THDPj + 1602 0x820ef9c _ZN7sp_head7executeEP3THD + 1096 0x820f87d _ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE + 1183 0x80f4ea9 _Z21mysql_execute_commandP3THD + 23053 0x80f7326 _Z11mysql_parseP3THDPcj + 330 0x80f7ccb _Z16dispatch_command19enum_server_commandP3THDPcj + 2157 0x80f8f3d _Z10do_commandP3THD + 537 0x80f9d02 handle_one_connection + 3350 0x83c1d56 start_thread + 98 0x841993e __clone + 110 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 0xa607670 = DELETE from g1 using g2,g1 where g2.id1=g1.id1 thd->thread_id=2619 The manual page at http://www.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 060619 19:40:37 mysqld restarted 060619 19:40: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... 060619 19:40:37 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 43665. InnoDB: Doing recovery: scanned up to log sequence number 0 43665 060619 19:40:37 InnoDB: Started; log sequence number 0 43665 060619 19:40:37 [Note] /home/sbester/servers/5.0-bk/bin/mysqld: ready for connections. Version: '5.0.23-debug' socket: '/tmp/my.sock' port: 3306 yes mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=8388572 read_buffer_size=131072 max_used_connections=45 max_connections=200 threads_connected=45 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 443384 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x90f02a0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x71985cc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80daa23 handle_segfault + 461 0x90a420 data.7108 + 9479156 0x943f7a0 __stop___libc_freeres_ptrs + 14346944 0x80f1fc0 _Z21mysql_execute_commandP3THD + 11044 0x820b6d5 _ZN13sp_instr_stmt9exec_coreEP3THDPj + 17 0x820c0e1 _ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr + 363 0x8210dca _ZN13sp_instr_stmt7executeEP3THDPj + 1602 0x820ef9c _ZN7sp_head7executeEP3THD + 1096 0x820f87d _ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE + 1183 0x80f4ea9 _Z21mysql_execute_commandP3THD + 23053 0x80f7326 _Z11mysql_parseP3THDPcj + 330 0x80f7ccb _Z16dispatch_command19enum_server_commandP3THDPcj + 2157 0x80f8f3d _Z10do_commandP3THD + 537 0x80f9d02 handle_one_connection + 3350 0x83c1d56 start_thread + 98 0x841993e __clone + 110 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 0x9447228 = DELETE from g1 using g2,g1 where g2.id1=g1.id1 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 060619 19:40:46 mysqld restarted 060619 19:40: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... 060619 19:40:46 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 43665. InnoDB: Doing recovery: scanned up to log sequence number 0 43665 060619 19:40:46 InnoDB: Started; log sequence number 0 43665 060619 19:40:46 [Note] /home/sbester/servers/5.0-bk/bin/mysqld: ready for connections. Version: '5.0.23-debug' socket: '/tmp/my.sock' port: 3306 yes mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=8388572 read_buffer_size=131072 max_used_connections=47 max_connections=200 threads_connected=47 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 443384 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8eccfb0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x7085cc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80daa23 handle_segfault + 461 0x531420 data.7108 + 5444596 0x8e01ed8 __stop___libc_freeres_ptrs + 7803384 0x80f1fc0 _Z21mysql_execute_commandP3THD + 11044 0x820b6d5 _ZN13sp_instr_stmt9exec_coreEP3THDPj + 17 0x820c0e1 _ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr + 363 0x8210dca _ZN13sp_instr_stmt7executeEP3THDPj + 1602 0x820ef9c _ZN7sp_head7executeEP3THD + 1096 0x820f87d _ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE + 1183 0x80f4ea9 _Z21mysql_execute_commandP3THD + 23053 0x80f7326 _Z11mysql_parseP3THDPcj + 330 0x80f7ccb _Z16dispatch_command19enum_server_commandP3THDPcj + 2157 0x80f8f3d _Z10do_commandP3THD + 537 0x80f9d02 handle_one_connection + 3350 0x83c1d56 start_thread + 98 0x841993e __clone + 110 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 0x8e03978 = DELETE from g1 using g2,g1 where g2.id1=g1.id1 thd->thread_id=1401 The manual page at http://www.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 060619 19:41:52 mysqld restarted 060619 19:41: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... 060619 19:41:52 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 43665. InnoDB: Doing recovery: scanned up to log sequence number 0 43665 060619 19:41:52 InnoDB: Started; log sequence number 0 43665 060619 19:41:52 [Note] /home/sbester/servers/5.0-bk/bin/mysqld: ready for connections. Version: '5.0.23-debug' socket: '/tmp/my.sock' port: 3306 yes mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=8388572 read_buffer_size=131072 max_used_connections=41 max_connections=200 threads_connected=41 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 443384 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xb7e0a4d0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x29f95cc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80daa23 handle_segfault + 461 0xd96420 data.7108 + 14246900 0xaa70e80 __stop___libc_freeres_ptrs + 37618080 0x80f1fc0 _Z21mysql_execute_commandP3THD + 11044 0x820b6d5 _ZN13sp_instr_stmt9exec_coreEP3THDPj + 17 0x820c0e1 _ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr + 363 0x8210dca _ZN13sp_instr_stmt7executeEP3THDPj + 1602 0x820ef9c _ZN7sp_head7executeEP3THD + 1096 0x820f87d _ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE + 1183 0x80f4ea9 _Z21mysql_execute_commandP3THD + 23053 0x80f7326 _Z11mysql_parseP3THDPcj + 330 0x80f7ccb _Z16dispatch_command19enum_server_commandP3THDPcj + 2157 0x80f8f3d _Z10do_commandP3THD + 537 0x80f9d02 handle_one_connection + 3350 0x83c1d56 start_thread + 98 0x841993e __clone + 110 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 0xaab6120 = DELETE from g1 using g2,g1 where g2.id1=g1.id1 thd->thread_id=2127 The manual page at http://www.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 060619 19:43:33 mysqld restarted 060619 19:43: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... 060619 19:43:33 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 43665. InnoDB: Doing recovery: scanned up to log sequence number 0 43665 060619 19:43:33 InnoDB: Started; log sequence number 0 43665 060619 19:43:33 [Note] /home/sbester/servers/5.0-bk/bin/mysqld: ready for connections. Version: '5.0.23-debug' socket: '/tmp/my.sock' port: 3306 yes mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=8388572 read_buffer_size=131072 max_used_connections=44 max_connections=200 threads_connected=44 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 443384 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xb7e60908 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x4895cc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80daa23 handle_segfault + 461 0xa33420 data.7108 + 10695668 0x93afd08 __stop___libc_freeres_ptrs + 13758504 0x80f1fc0 _Z21mysql_execute_commandP3THD + 11044 0x820b6d5 _ZN13sp_instr_stmt9exec_coreEP3THDPj + 17 0x820c0e1 _ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr + 363 0x8210dca _ZN13sp_instr_stmt7executeEP3THDPj + 1602 0x820ef9c _ZN7sp_head7executeEP3THD + 1096 0x820f87d _ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE + 1183 0x80f4ea9 _Z21mysql_execute_commandP3THD + 23053 0x80f7326 _Z11mysql_parseP3THDPcj + 330 0x80f7ccb _Z16dispatch_command19enum_server_commandP3THDPcj + 2157 0x80f8f3d _Z10do_commandP3THD + 537 0x80f9d02 handle_one_connection + 3350 0x83c1d56 start_thread + 98 0x841993e __clone + 110 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 0x938ee90 = DELETE from g1 using g2,g1 where g2.id1=g1.id1 thd->thread_id=1848 The manual page at http://www.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 060619 19:44:53 mysqld restarted 060619 19:44: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... 060619 19:44:54 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 43665. InnoDB: Doing recovery: scanned up to log sequence number 0 43665 060619 19:44:54 InnoDB: Started; log sequence number 0 43665 060619 19:44:54 [Note] /home/sbester/servers/5.0-bk/bin/mysqld: ready for connections. Version: '5.0.23-debug' socket: '/tmp/my.sock' port: 3306 yes mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=8388572 read_buffer_size=131072 max_used_connections=42 max_connections=200 threads_connected=35 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 443384 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xb7c0f500 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xd905cc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80daa23 handle_segfault + 461 0xf2e420 data.7108 + 15918068 0xad3ff60 __stop___libc_freeres_ptrs + 40563328 0x80f1fc0 _Z21mysql_execute_commandP3THD + 11044 0x820b6d5 _ZN13sp_instr_stmt9exec_coreEP3THDPj + 17 0x820c0e1 _ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr + 363 0x8210dca _ZN13sp_instr_stmt7executeEP3THDPj + 1602 0x820ef9c _ZN7sp_head7executeEP3THD + 1096 0x820f87d _ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE + 1183 0x80f4ea9 _Z21mysql_execute_commandP3THD + 23053 0x80f7326 _Z11mysql_parseP3THDPcj + 330 0x80f7ccb _Z16dispatch_command19enum_server_commandP3THDPcj + 2157 0x80f8f3d _Z10do_commandP3THD + 537 0x80f9d02 handle_one_connection + 3350 0x83c1d56 start_thread + 98 0x841993e __clone + 110 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 0xad3b9f0 = DELETE from g1 using g2,g1 where g2.id1=g1.id1 thd->thread_id=5191 The manual page at http://www.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 060619 19:48:48 mysqld restarted 060619 19:48: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... 060619 19:48:49 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 43665. InnoDB: Doing recovery: scanned up to log sequence number 0 43665 060619 19:48:49 InnoDB: Started; log sequence number 0 43665 060619 19:48:49 [Note] /home/sbester/servers/5.0-bk/bin/mysqld: ready for connections. Version: '5.0.23-debug' socket: '/tmp/my.sock' port: 3306 yes mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=8388572 read_buffer_size=131072 max_used_connections=53 max_connections=200 threads_connected=35 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 443384 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xb7c9e180 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0x5e8b5cc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80daa23 handle_segfault + 461 0x4cf420 data.7108 + 5043188 0x92ca590 __stop___libc_freeres_ptrs + 12818608 0x80f1fc0 _Z21mysql_execute_commandP3THD + 11044 0x820b6d5 _ZN13sp_instr_stmt9exec_coreEP3THDPj + 17 0x820c0e1 _ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr + 363 0x8210dca _ZN13sp_instr_stmt7executeEP3THDPj + 1602 0x820ef9c _ZN7sp_head7executeEP3THD + 1096 0x820f87d _ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE + 1183 0x80f4ea9 _Z21mysql_execute_commandP3THD + 23053 0x80f7326 _Z11mysql_parseP3THDPcj + 330 0x80f7ccb _Z16dispatch_command19enum_server_commandP3THDPcj + 2157 0x80f8f3d _Z10do_commandP3THD + 537 0x80f9d02 handle_one_connection + 3350 0x83c1d56 start_thread + 98 0x841993e __clone + 110 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 0x934c5a8 = DELETE from g1 using g2,g1 where g2.id1=g1.id1 thd->thread_id=1372 The manual page at http://www.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 060619 19:49:52 mysqld restarted 060619 19:49: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... 060619 19:49:53 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 43665. InnoDB: Doing recovery: scanned up to log sequence number 0 43665 060619 19:49:53 InnoDB: Started; log sequence number 0 43665 060619 19:49:53 [Note] /home/sbester/servers/5.0-bk/bin/mysqld: ready for connections. Version: '5.0.23-debug' socket: '/tmp/my.sock' port: 3306 yes mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=8388572 read_buffer_size=131072 max_used_connections=43 max_connections=200 threads_connected=43 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 443384 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xb7c2bff0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xac45cc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x80daa23 handle_segfault + 461 0xfc4420 data.7108 + 16532468 0x97bfd68 __stop___libc_freeres_ptrs + 18018440 0x80f1fc0 _Z21mysql_execute_commandP3THD + 11044 0x820b6d5 _ZN13sp_instr_stmt9exec_coreEP3THDPj + 17 0x820c0e1 _ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr + 363 0x8210dca _ZN13sp_instr_stmt7executeEP3THDPj + 1602 0x820ef9c _ZN7sp_head7executeEP3THD + 1096 0x820f87d _ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE + 1183 0x80f4ea9 _Z21mysql_execute_commandP3THD + 23053 0x80f7326 _Z11mysql_parseP3THDPcj + 330 0x80f7ccb _Z16dispatch_command19enum_server_commandP3THDPcj + 2157 0x80f8f3d _Z10do_commandP3THD + 537 0x80f9d02 handle_one_connection + 3350 0x83c1d56 start_thread + 98 0x841993e __clone + 110 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 0x9803bc0 = DELETE from g1 using g2,g1 where g2.id1=g1.id1 thd->thread_id=3415 The manual page at http://www.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 060619 19:52:35 mysqld restarted 060619 19:52: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... 060619 19:52:35 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 43665. InnoDB: Doing recovery: scanned up to log sequence number 0 43665 060619 19:52:35 InnoDB: Started; log sequence number 0 43665 060619 19:52:36 [Note] /home/sbester/servers/5.0-bk/bin/mysqld: ready for connections. Version: '5.0.23-debug' socket: '/tmp/my.sock' port: 3306 yes