060619 19:13:59  mysqld started
060619 19:13:59 [Note] /home/sbester/servers/5.1-bk/bin/mysqld: ready for connections.
Version: '5.1.12-beta-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=39
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=0xb7e7e3c8
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=0x9766ac, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8187a6b handle_segfault + 461
0x869420 (?)
0x86432e8 _end + 832888
0x81a0a26 _Z21mysql_execute_commandP3THD + 11016
0x82d23dd _ZN13sp_instr_stmt9exec_coreEP3THDPj + 17
0x82d2de9 _ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr + 363
0x82d7b9e _ZN13sp_instr_stmt7executeEP3THDPj + 1686
0x82d5c7e _ZN7sp_head7executeEP3THD + 1090
0x82d65e2 _ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE + 1334
0x81a3d1c _Z21mysql_execute_commandP3THD + 24062
0x81a62bc _Z11mysql_parseP3THDPcj + 378
0x81a6cad _Z16dispatch_command19enum_server_commandP3THDPcj + 2199
0x81a7f52 _Z10do_commandP3THD + 516
0x81a8b39 handle_one_connection + 2871
0x880b80 (?)
0x597dee (?)
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 0x876b750 = DELETE from g1 using g2,g1 where g2.id1=g1.id1
thd->thread_id=1000
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:15:25  mysqld restarted
060619 19:15:25 [Note] /home/sbester/servers/5.1-bk/bin/mysqld: ready for connections.
Version: '5.1.12-beta-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=0xb7e38710
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=0x3f676ac, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8187a6b handle_segfault + 461
0x6eb420 (?)
0xa4ce2f8 _end + 32859528
0x81a0a26 _Z21mysql_execute_commandP3THD + 11016
0x82d23dd _ZN13sp_instr_stmt9exec_coreEP3THDPj + 17
0x82d2de9 _ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr + 363
0x82d7b9e _ZN13sp_instr_stmt7executeEP3THDPj + 1686
0x82d5c7e _ZN7sp_head7executeEP3THD + 1090
0x82d65e2 _ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE + 1334
0x81a3d1c _Z21mysql_execute_commandP3THD + 24062
0x81a62bc _Z11mysql_parseP3THDPcj + 378
0x81a6cad _Z16dispatch_command19enum_server_commandP3THDPcj + 2199
0x81a7f52 _Z10do_commandP3THD + 516
0x81a8b39 handle_one_connection + 2871
0x880b80 (?)
0x597dee (?)
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 0xa74bae0 = DELETE from g1 using g2,g1 where g2.id1=g1.id1
thd->thread_id=1683
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:17:00  mysqld restarted
060619 19:17:01 [Note] /home/sbester/servers/5.1-bk/bin/mysqld: ready for connections.
Version: '5.1.12-beta-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=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=0xb7c04058
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=0xc516ac, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8187a6b handle_segfault + 461
0x47c420 (?)
0xa2ccbf8 _end + 30756488
0x81a0a26 _Z21mysql_execute_commandP3THD + 11016
0x82d23dd _ZN13sp_instr_stmt9exec_coreEP3THDPj + 17
0x82d2de9 _ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr + 363
0x82d7b9e _ZN13sp_instr_stmt7executeEP3THDPj + 1686
0x82d5c7e _ZN7sp_head7executeEP3THD + 1090
0x82d65e2 _ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE + 1334
0x81a3d1c _Z21mysql_execute_commandP3THD + 24062
0x81a62bc _Z11mysql_parseP3THDPcj + 378
0x81a6cad _Z16dispatch_command19enum_server_commandP3THDPcj + 2199
0x81a7f52 _Z10do_commandP3THD + 516
0x81a8b39 handle_one_connection + 2871
0x880b80 (?)
0x597dee (?)
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 0xa4aefb0 = DELETE from g1 using g2,g1 where g2.id1=g1.id1
thd->thread_id=1049
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:17:57  mysqld restarted
060619 19:17:58 [Note] /home/sbester/servers/5.1-bk/bin/mysqld: ready for connections.
Version: '5.1.12-beta-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=0xb7c0ac18
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=0x8676ac, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8187a6b handle_segfault + 461
0x579420 (?)
0x9f20cd0 _end + 26906464
0x81a0a26 _Z21mysql_execute_commandP3THD + 11016
0x82d23dd _ZN13sp_instr_stmt9exec_coreEP3THDPj + 17
0x82d2de9 _ZN13sp_lex_keeper23reset_lex_and_exec_coreEP3THDPjbP8sp_instr + 363
0x82d7b9e _ZN13sp_instr_stmt7executeEP3THDPj + 1686
0x82d5c7e _ZN7sp_head7executeEP3THD + 1090
0x82d65e2 _ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE + 1334
0x81a3d1c _Z21mysql_execute_commandP3THD + 24062
0x81a62bc _Z11mysql_parseP3THDPcj + 378
0x81a6cad _Z16dispatch_command19enum_server_commandP3THDPcj + 2199
0x81a7f52 _Z10do_commandP3THD + 516
0x81a8b39 handle_one_connection + 2871
0x880b80 (?)
0x200dee (?)
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 0x9ecce78 = DELETE from g1 using g2,g1 where g2.id1=g1.id1
thd->thread_id=5606
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:23:06  mysqld restarted
060619 19:23:06 [Note] /home/sbester/servers/5.1-bk/bin/mysqld: ready for connections.
Version: '5.1.12-beta-debug'  socket: '/tmp/my.sock'  port: 3306  yes