Bug #65860 mysqld was crashed wihile using filesort
Submitted: 10 Jul 2012 5:48 Modified: 11 Dec 2013 6:44
Reporter: zhai weixiang (OCA) Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: DML Severity:S1 (Critical)
Version:5.1,5.5,5.6 OS:Linux
Assigned to: CPU Architecture:Any

[10 Jul 2012 5:48] zhai weixiang
Description:
the crash seems related to some bug of filesort. Our MySQL version is 5.1.48. And the same sql may crash multiple instances.

there are  two different  backtraces we had met.

case 1:
use innodb

backtrace in error log:
111109 15:28:47 - 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.
and this may fail.

key_buffer_size=104857600
read_buffer_size=1048576
max_used_connections=141
max_threads=1000
threads_connected=104
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1236696 K
bytes of memory 
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x2aadc23ec210
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_bottom = 0x489e10f0 thread_stack 0x80000
/u01/mysql/libexec/mysqld(my_print_stacktrace+0x35)[0x884b95]
/u01/mysql/libexec/mysqld(handle_segfault+0x31d)[0x5bcfcd]
/lib64/libpthread.so.0[0x3d14e0e7c0]
/lib64/libc.so.6(memcpy+0xe)[0x3d1427bdbe]
/u01/mysql/libexec/mysqld(_Z13merge_buffersP13st_sort_paramP11st_io_cacheS2_PhP10st_buffpekS5_S5_i+0x565)[0x6b4de5]
/u01/mysql/libexec/mysqld(_Z8filesortP3THDP8st_tableP13st_sort_fieldjP10SQL_SELECTmbPm+0xebd)[0x6b622d]
/u01/mysql/libexec/mysqld[0x63638b]
/u01/mysql/libexec/mysqld(_ZN4JOIN4execEv+0x806)[0x644206]
/u01/mysql/libexec/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex
+0x168)[0x645ff8]
/u01/mysql/libexec/mysqld(_Z21mysql_derived_fillingP3THDP6st_lexP10TABLE_LIST+0x116)[0x70f0f6]
/u01/mysql/libexec/mysqld(_Z20mysql_handle_derivedP6st_lexPFbP3THDS0_P10TABLE_LISTE+0x69)[0x70ebe9]
/u01/mysql/libexec/mysqld(_Z28open_and_lock_tables_derivedP3THDP10TABLE_LISTb+0x141)[0x6170e1]
/u01/mysql/libexec/mysqld[0x5c7b2e]
/u01/mysql/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x33e1)[0x5ced01]
/u01/mysql/libexec/mysqld(Z11mysql_parseP3THDPKcjPS2+0x20b)[0x5d3a2b]
/u01/mysql/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x3e0)[0x5d3e10]
/u01/mysql/libexec/mysqld(_Z10do_commandP3THD+0xe6)[0x5d5066]
/u01/mysql/libexec/mysqld(handle_one_connection+0x5c6)[0x5c55c6]
/lib64/libpthread.so.0[0x3d14e064a7]
/lib64/libc.so.6(clone+0x6d)[0x3d142d3c2d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x2aadad7f89e0 is an invalid pointer 
thd->thread_id=1705080
thd->killed=NOT_KILLED

case 2
use myisam

backtrace in error log:

thd: 0x27b9e770
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_bottom = 0x4f3bb0f0 thread_stack 0x80000
/u01/mysql/libexec/mysqld(my_print_stacktrace+0x2e)[0x8798ae]
/u01/mysql/libexec/mysqld(handle_segfault+0x322)[0x5b8272]
/lib64/libpthread.so.0[0x3ed4c0e7c0]
/u01/mysql/libexec/mysqld[0x86add1]
/u01/mysql/libexec/mysqld(queue_insert+0x4e)[0x86b36e]
/u01/mysql/libexec/mysqld(_Z13merge_buffersP13st_sort_paramP11st_io_cacheS2_PhP10st_buffpekS5_S5_i+0x17c)[0x6aaafc]
/u01/mysql/libexec/mysqld(_Z8filesortP3THDP8st_tableP13st_sort_fieldjP10SQL_SELECTmbPm+0xf1d)[0x6ac2bd]
/u01/mysql/libexec/mysqld[0x62ebd3]
/u01/mysql/libexec/mysqld(_ZN4JOIN4execEv+0x838)[0x63c548]
/u01/mysql/libexec/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x198)[0x63e2a8]
/u01/mysql/libexec/mysqld(_Z13handle_selectP3THDP6st_lexP13select_resultm+0x169)[0x63ebe9]
/u01/mysql/libexec/mysqld[0x5c2bec]
/u01/mysql/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x3365)[0x5c9cf5]
/u01/mysql/libexec/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x231)[0x5ce8e1]
/u01/mysql/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x3f3)[0x5cece3]
/u01/mysql/libexec/mysqld(_Z10do_commandP3THD+0xe4)[0x5cff74]
/u01/mysql/libexec/mysqld(handle_one_connection+0x5b7)[0x5c0647]
/lib64/libpthread.so.0[0x3ed4c064a7]
/lib64/libc.so.6(clone+0x6d)[0x3ed40d3c2d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x2aaef06990e0 is an invalid pointer
thd->thread_id=47445823
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
mysqld: my_new.cc:51: int __cxa_pure_virtual(): Assertion `! "Aborted: pure virtual method called."' failed.
Fatal signal 6 while backtracing
 

How to repeat:
I  don't know

Suggested fix:
I don't know.
[10 Jul 2012 6:02] Valeriy Kravchuk
Please, check if the same problem still happens with a newer version, 5.1.63.
[11 Aug 2012 1:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[28 Oct 2013 5:42] zhai weixiang
I know someone has reported a bug that pointed out the root cause of bug#65860( with suitable sort_buffer_size, max_sort_length and dataset , can reproduce the crash every time ) . But unfortunately that's invisible. Anyone can mark this bug as a duplicate of that one?

thanks in advance!
[11 Dec 2013 6:44] zhai weixiang
This bug should have been fixed in the latest MySQL5.6.15.

Change log entry:

The filesort implementation sometimes failed to allocate enough buffer space, leading to a server exit. (Bug #17326567)

Close this bug report.