Bug #58604 crash in cleanup code of explain partitions after killing connection
Submitted: 30 Nov 2010 21:28 Modified: 2 Dec 2010 15:17
Reporter: Shane Bester (Platinum Quality Contributor) Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Optimizer Severity:S1 (Critical)
Version:5.5.7, 5.5.9, 5.6.1 OS:Any
Assigned to: Tor Didriksen CPU Architecture:Any
Tags: KILL
Triage: Triaged: D1 (Critical)

[30 Nov 2010 21:28] Shane Bester
Description:
seen this a few times in 5.5.7:
mysqld.exe!free_io_cache()[sql_base.cc:883]               
mysqld.exe!JOIN::cleanup()[sql_select.cc:7098]            
mysqld.exe!JOIN::destroy()[sql_select.cc:2414]            
mysqld.exe!st_select_lex::cleanup()[sql_union.cc:810]     
mysqld.exe!st_select_lex_unit::cleanup()[sql_union.cc:675]
mysqld.exe!st_select_lex::cleanup()[sql_union.cc:816]     
mysqld.exe!st_select_lex_unit::cleanup()[sql_union.cc:675]
mysqld.exe!st_select_lex::cleanup()[sql_union.cc:816]     
mysqld.exe!st_select_lex_unit::cleanup()[sql_union.cc:675]
mysqld.exe!st_select_lex::cleanup()[sql_union.cc:816]     
mysqld.exe!st_select_lex_unit::cleanup()[sql_union.cc:675]
mysqld.exe!st_select_lex::cleanup()[sql_union.cc:816]     
mysqld.exe!st_select_lex_unit::cleanup()[sql_union.cc:675]
mysqld.exe!mysql_execute_command()[sql_parse.cc:4382]     
mysqld.exe!mysql_parse()[sql_parse.cc:5499]               
mysqld.exe!dispatch_command()[sql_parse.cc:1032]          
mysqld.exe!do_command()[sql_parse.cc:769]                 
mysqld.exe!do_handle_one_connection()[sql_connect.cc:745] 
mysqld.exe!handle_one_connection()[sql_connect.cc:684]    
mysqld.exe!pthread_start()[my_winthread.c:61]             
mysqld.exe!_callthreadstartex()[threadex.c:348]           
mysqld.exe!_threadstartex()[threadex.c:326]               
kernel32.dll!FlsSetValue()                                

How to repeat:
no pretty testcase yet. the crashing queries are all large joins, unions, and views.  will have to run many valgrind tests and catch the initial error.
[1 Dec 2010 7:29] Shane Bester
caught in valgrind once. it's not repeatable when rerunning the query.

Attachment: bug58604_valgrind_output.txt (text/plain), 31.08 KiB.

[1 Dec 2010 8:22] Shane Bester
import this file. then "call killit()" in one connection and "call p()" in another connection!!!

Attachment: bug58604.sql (text/x-sql), 16.61 KiB.

[1 Dec 2010 8:25] Shane Bester
release build crashes like this.
debug build crashes like in bug 58619
marking bug 58619 as a duplicate of this
[1 Dec 2010 8:29] Shane Bester
note:  SP is not needed here, and only provided for convenience to repeat a problem quickly. a user can kill his own query by hitting ctrl-c in mysql client at the precise moment.
[1 Dec 2010 18:31] Sveta Smirnova
Thank you for the report.

I can not repeat described behavior. How do you start server?
[2 Dec 2010 3:51] Shane Bester
Sveta:

mysqld --no-defaults --skip-gr --skip-na

Run multiple threads of "call p" if you cant repeat it. both my release and debug windows and linux builds, with and without valgrind crashed fairly easy.

notice the information_schema.processlist table should exist, and please dont have any more connections to the server than the testcase requires otherwise you'll be killing irrelevant threads.
[2 Dec 2010 15:17] Sveta Smirnova
Thank you for the feedback.

Verified as described using options provided.
[2 Dec 2010 21:32] Shane Bester
maybe related: bug 58676