Bug #20503 DB crash after SELECT
Submitted: 16 Jun 2006 14:33 Modified: 23 Oct 2006 14:17
Reporter: Sławomir Mrozik Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:5.0.19,5.0BK,5.0.22,5.1BK OS:Any (*)
Assigned to: Evgeny Potemkin CPU Architecture:Any

[16 Jun 2006 14:33] Sławomir Mrozik
Description:
I have problem with selecting data from DB.
After sending query (listed in Private comment) MySQL server crashes (once hang up with open socket but without response - tested with telnet).

Query was tested on two different mysql 5.0.19 and one 4.1.13 servers, compiled from the source, OS linux with kernel 2.4.x,
Database has aprox. 500 records with polish UTF-8 data.

How to repeat:
execute query
[16 Jun 2006 15:00] Valeriy Kravchuk
Thank you for a problem report. Please, try to repeat with a newer version, 5.0.22, and inform about the results. In case of similar crash, please, send the resolved stack trace also.
[16 Jun 2006 17:26] Shane Bester
5.0.23BK and 5.1BK on windows and linux crashed
4.1BK didn't crash.

THD::cleanup_after_query()  Line 565
dispatch_command()  Line 1747	C++
do_command(THD * thd=0x07f4eae0)  Line 1531
handle_one_connection()  Line 1174+
pthread_start()  Line 63
_threadstart()  Line 196
_BaseThreadStart@8()
[23 Jun 2006 12:52] Miguel Solorzano
Back trace on Linux Suse

Attachment: bt20503.txt (text/plain), 2.81 KiB.

[23 Jul 2006 23: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".
[24 Jul 2006 7:51] Sławomir Mrozik
Reopened because all data was delivered by me, Shane Bester and Miguel Solorzano
[11 Aug 2006 12:00] Sergey Vojtovich
Shane,

this bug is in open state for almost 20 days. Could you either reverify or
close it?
[11 Aug 2006 12:50] Shane Bester
my 5.0.24 and 5.0.25 on windows and linux still crash using my testcase.
query returns...

    -> ORDER BY
    -> cccccccc, cccccccc;
Empty set (0.00 sec)

but in background mysqld is crashed!
WARNING: Frame IP not in any known module. Following frames may be wrong.
0x120ca87
mysqld_nt!Query_arena::free_items+0x1d
mysqld_nt!THD::cleanup_after_query+0x29
mysqld_nt!dispatch_command+0x562
mysqld_nt!do_command+0xad
mysqld_nt!handle_one_connection+0x26e
mysqld_nt!pthread_start+0x3b
mysqld_nt!_threadstart+0x6c
0x11f8230

Stack range sanity check OK, backtrace follows:
0x80db37d handle_segfault + 461
0x7eb420 data.7108 + 8303604
0x8f data.7108 + 99
0x80f820f _Z11mysql_parseP3THDPcj + 533
0x80f8d54 _Z16dispatch_command19enum_server_commandP3THDPcj + 2776
0x80fa005 _Z10do_commandP3THD + 537
0x80fad62 handle_one_connection + 3246
0x83c6856 start_thread + 98
0x841e3ae __clone + 110
[11 Aug 2006 15:18] Sergey Vojtovich
Shane, this way could you please provide _complete_ test case. I can see only DDL statements and SELECT that crashes mysqld. No INSERT statements, that is no data set.
[11 Aug 2006 15:28] Miguel Solorzano
Showing crash

Attachment: bug20503.PNG (image/png, text), 38.39 KiB.

[11 Aug 2006 15:29] Miguel Solorzano
Sergey,

You don't need data for to get the crash, please see picture attached.
[11 Aug 2006 16:35] Sergey Vojtovich
Shane, Miguel.

Thanks for this description. I was able to repeat this bug on linux. It seems something wicked is happening - both mysqld and valgrind have crashed with this test case. :)

I'll look deeper into this problem and will check if it really belongs to SE.
[14 Aug 2006 16:26] Sergey Vojtovich
bug#21511 was marked as a duplicate of this bug.
[11 Sep 2006 16:38] Nicholas Gresham
still present in 5.0.24

any progress?
[28 Sep 2006 20:49] Bugs System
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/12781

ChangeSet@1.2286, 2006-09-29 00:50:00+04:00, evgen@moonbone.local +3 -0
  Fixed bug#20503: Server crash due to the ORDER clause not taken into account
  while space allocation
  
  Under some circumstances DISTINCT clause can be converted to grouping.
  In such cases grouping is performed by all items in the select list.
  If an ORDER clause is present then items from it is prepended to group list.
  But the case with ORDER wasn't taken into account when allocating the
  array for sum functions. This leads to memory corruption and crash.
  
  The JOIN::alloc_func_list() function now allocates additional space if there
  is an ORDER by clause is specified and DISTINCT -> GROUP BY optimization is
  possible.
[21 Oct 2006 9:11] Georgi Kodinov
Pushed in 5.0.27/5.1.13-beta
[23 Oct 2006 14:17] Paul Dubois
Noted in 5.0.27, 5.1.13 changelogs.