Description:
Mysqld crash...all in berkeley_cmp_packed_key_FP4 but with different queries.
stack dump:
0x80d6caf handle_segfault__Fi + 431
0x40037f05 _end + 935642501
0x8125f47 berkeley_cmp_packed_key__FP4__dbPC8__db_dbtT1 + 135
0x8174c5c __bam_cmp + 288
0x81b8a86 __bam_search + 886
0x81ae5dd __bam_c_search + 1633
0x81ac141 __bam_c_get + 1297
0x8188960 __db_c_get + 840
0x8184a6b __db_get + 323
0x8128411 rnd_pos__11ha_berkeleyPcT1 + 97
0x811e15a rr_from_pointers__FP14st_read_record + 58
0x80fe94e join_init_read_record__FP13st_join_table + 78
0x80fde6c sub_select__FP4JOINP13st_join_tableb + 76
0x80fdbe4 do_select__FP4JOINPt4List1Z4ItemP8st_tableP9Procedure + 404
0x80f67a4 mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st_orderT4T3T4UiP13select_result + 7428
0x80dd5ef mysql_execute_command__Fv + 847
0x80e0a05 mysql_parse__FP3THDPcUi + 69
0x80dc803 do_command__FP3THD + 1283
0x80dbd69 handle_one_connection__FPv + 585
How to repeat:
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=8388600
record_buffer=131072
sort_buffer=2097144
max_used_connections=19
max_connections=100
threads_connected=18
It is possible that mysqld could use up to
key_buffer_size + (record_buffer + sort_buffer)*max_connections = 225791 K
bytes of memory
Hope that's ok, if not, decrease some variables in the equation
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...
Stack range sanity check OK, backtrace follows:
0x80d6caf
0x40037f05
0x8125f47
0x8174c5c
0x81b8a86
0x81ae5dd
0x81ac141
0x8188960
0x8184a6b
0x8128411
0x811e15a
0x80fe94e
0x80fde6c
0x80fdbe4
0x80f67a4
0x80dd5ef
0x80e0a05
0x80dc803
0x80dbd69
Stack trace seems successful - bottom reached
Please read http://www.mysql.com/doc/U/s/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 0x843eb10 = select * from titles_list
where topic_id = 'U007292d3'
order by ROUND(title_ordinal) LIMIT 1000
thd->thread_id=238
Successfully dumped variables, if you ran with --log, take a look at the
details of what thread 238 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 09:47:30 mysqld restarted
Cannot initialize InnoDB as 'innodb_data_file_path' is not set.
If you do not want to use transactional InnoDB tables, add a line
skip-innodb
to the [mysqld] section of init parameters in your my.cnf
or my.ini. If you want to use InnoDB tables, add to the [mysqld]
section, for example,
innodb_data_file_path = ibdata1:10M:autoextend
But to get good performance you should adjust for your hardware
the InnoDB startup options listed in section 2 at
http://www.innodb.com/ibman.html