MySQL Bugs: #52164: Assertion failed: param.sort_length, file .\filesort.cc, line 149

Bug #52164	Assertion failed: param.sort_length, file .\filesort.cc, line 149
Submitted:	18 Mar 2010 6:05	Modified:	7 Jul 2010 19:21
Reporter:	Shane Bester (Platinum Quality Contributor)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: DML	Severity:	S1 (Critical)
Version:	5.1.45-debug,5.6.99-m4-debug	OS:	Any
Assigned to:	Sergei Glukhov	CPU Architecture:	Any
Tags:	assertion

Description:
Version: '5.6.99-m4-debug'  socket: ''  port: 3306  Source distribution
Assertion failed: param.sort_length, file .\filesort.cc, line 149

mysqld.exe!my_sigabrt_handler()[my_thr_init.c:519]
mysqld.exe!raise()[winsig.c:590]
mysqld.exe!abort()[abort.c:71]
mysqld.exe!_wassert()[assert.c:212]
mysqld.exe!filesort()[filesort.cc:149]
mysqld.exe!create_sort_index()[sql_select.cc:13904]
mysqld.exe!JOIN::exec()[sql_select.cc:2260]
mysqld.exe!mysql_select()[sql_select.cc:2508]
mysqld.exe!handle_select()[sql_select.cc:271]
mysqld.exe!execute_sqlcom_select()[sql_parse.cc:4703]
mysqld.exe!mysql_execute_command()[sql_parse.cc:2191]
mysqld.exe!mysql_parse()[sql_parse.cc:5735]
mysqld.exe!dispatch_command()[sql_parse.cc:1024]
mysqld.exe!do_command()[sql_parse.cc:710]
mysqld.exe!do_handle_one_connection()[sql_connect.cc:1174]
mysqld.exe!handle_one_connection()[sql_connect.cc:1113]
mysqld.exe!pthread_start()[my_winthread.c:61]
mysqld.exe!_callthreadstartex()[threadex.c:348]
mysqld.exe!_threadstartex()[threadex.c:331]

How to repeat:
#on debug build run:

drop table if exists `t1`;
create table `t1` (`a` longblob not null) engine=myisam;
insert into `t1` values (),(); 
select 1 from `t1`,`t1` `t2`
order by quote(`t1`.`a`);

Thank you for the bug report. Verified just as described on Ubuntu:

...
Version: '5.6.99-m4-debug'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
mysqld: filesort.cc:149: ha_rows filesort(THD*, TABLE*, SORT_FIELD*, uint, SQL_SELECT*, ha_rows, bool, ha_rows*): Assertion `param.sort_length' failed.
100318 10:29:01 - mysqld got signal 6 ;
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=8388608
read_buffer_size=131072
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 337841 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0x93ec1a0
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 = 0xa88443b0 thread_stack 0x30000
/home2/openxs/dbs/next-mr/libexec/mysqld(my_print_stacktrace+0x26)[0x877fd41]
/home2/openxs/dbs/next-mr/libexec/mysqld(handle_segfault+0x2ee)[0x82c7452]
[0xb7789420]
/lib/tls/i686/cmov/libc.so.6(abort+0x101)[0xb75cca01]
/lib/tls/i686/cmov/libc.so.6(__assert_fail+0xee)[0xb75c410e]
/home2/openxs/dbs/next-mr/libexec/mysqld(_Z8filesortP3THDP5TABLEP13st_sort_fieldjP10SQL_SELECTybPy+0x20a)[0x8415bb4]
/home2/openxs/dbs/next-mr/libexec/mysqld[0x835a769]
/home2/openxs/dbs/next-mr/libexec/mysqld(_ZN4JOIN4execEv+0x1fff)[0x8374e11]
/home2/openxs/dbs/next-mr/libexec/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x30d)[0x836fce9]
/home2/openxs/dbs/next-mr/libexec/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x1ec)[0x83753d6]
/home2/openxs/dbs/next-mr/libexec/mysqld[0x82d8d4b]
/home2/openxs/dbs/next-mr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x9c1)[0x82daa81]
/home2/openxs/dbs/next-mr/libexec/mysqld(_Z11mysql_parseP3THDPKcjPS2_+0x229)[0x82e2cd1]
/home2/openxs/dbs/next-mr/libexec/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x9e0)[0x82e3846]
/home2/openxs/dbs/next-mr/libexec/mysqld(_Z10do_commandP3THD+0x241)[0x82e4da5]
/home2/openxs/dbs/next-mr/libexec/mysqld(_Z24do_handle_one_connectionP3THD+0x15b)[0x82d2001]
/home2/openxs/dbs/next-mr/libexec/mysqld(handle_one_connection+0x25)[0x82d20bf]
/lib/tls/i686/cmov/libpthread.so.0[0xb77684fb]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7676e5e]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x945f820 = select 1 from `t1`,`t1` `t2`
order by quote(`t1`.`a`)
thd->thread_id=1

debug assertions are here for a reason: to catch problems that exist.
although generally a release binary will not crash, we might get obscure
or wrong results later, or worse.  debug assertions should get same priority imho.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/104083

3414 Sergey Glukhov	2010-03-23
      Bug#52164 Assertion failed: param.sort_length, file .\filesort.cc, line 149
      The crash happens because of incorrect max_length calculation
      due to overflow, max_length is set to 0 and it leads to
      assert failure. The fix is to cast expression result to
      ulonglong variable and adjust it if the result exceeds
      MAX_BLOB_WIDTH.
     @ mysql-test/r/func_str.result
        test result
     @ mysql-test/t/func_str.test
        test case
     @ sql/item_strfunc.h
        cast expression result to ulonglong variable and
        adjust it if the result exceeds MAX_BLOB_WIDTH.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/104401

3425 Sergey Glukhov	2010-03-26
       Bug#52164 Assertion failed: param.sort_length, file .\filesort.cc, line 149
      The crash happens because of incorrect max_length calculation
      in QUOTE function(due to overflow). max_length is set
      to 0 and it leads to assert failure.
      The fix is to cast expression result to
      ulonglong variable and adjust it if the
      result exceeds MAX_BLOB_WIDTH.
     @ mysql-test/r/func_str.result
        test case
     @ mysql-test/t/func_str.test
        test case
     @ sql/item_strfunc.h
        cast expression result to ulonglong variable and
        adjust it if the result exceeds MAX_BLOB_WIDTH.

Pushed into 5.1.46 (revid:sergey.glukhov@sun.com-20100405111026-7kz1p8qlzglqgfmu) (version source revid:sergey.glukhov@sun.com-20100326054935-1oa046hh5v9gayl5) (merge vers: 5.1.46) (pib:16)

No direct end-user impact so closing without further action.

Pushed into mysql-next-mr (revid:alik@sun.com-20100524190136-egaq7e8zgkwb9aqi) (version source revid:alik@sun.com-20100422150750-vp0n37kp9ywq5ghf) (pib:16)

Pushed into 6.0.14-alpha (revid:alik@sun.com-20100524190941-nuudpx60if25wsvx) (version source revid:alik@sun.com-20100422150658-fkhgnwwkyugtxrmu) (merge vers: 6.0.14-alpha) (pib:16)

Pushed into 5.5.5-m3 (revid:alik@sun.com-20100524185725-c8k5q7v60i5nix3t) (version source revid:alexey.kopytov@sun.com-20100402151743-xowc2u930h729jsy) (merge vers: 5.5.4-m3) (pib:16)

see also bug #54459 !

Pushed into 5.1.47-ndb-7.0.16 (revid:martin.skold@mysql.com-20100617114014-bva0dy24yyd67697) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)

Pushed into 5.1.47-ndb-6.2.19 (revid:martin.skold@mysql.com-20100617115448-idrbic6gbki37h1c) (version source revid:martin.skold@mysql.com-20100609211156-tsac5qhw951miwtt) (merge vers: 5.1.46-ndb-6.2.19) (pib:16)

Pushed into 5.1.47-ndb-6.3.35 (revid:martin.skold@mysql.com-20100617114611-61aqbb52j752y116) (version source revid:vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457) (merge vers: 5.1.46) (pib:16)