Details
-
Type:
Bug
-
Status: Closed
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: None
-
Labels:
Description
The following query:
SELECT table2 .`col_date_key` field5 , table2 .`col_int_key` field6 FROM CC table1 STRAIGHT_JOIN ( CC table2 JOIN CC table3 ON table3 .`col_varchar_nokey` ) ON table2 .`col_int_nokey` AND table3 .`col_varchar_key` = table2 .`col_varchar_nokey` ORDER BY table1 .`col_date_key`
could not be killed with either KILL or KILL QUERY. It seems that there is a long-running loop in the following backtrace that does not check for query kills.
#0 0x082dc575 in JOIN_CACHE_HASHED::get_next_key_ref (this=0xb6968d0,
key_ref_ptr=0xb680a41 "\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245"...) at sql_select.h:1181
#1 0x082da326 in JOIN_CACHE_HASHED::key_search (this=0xb6968d0, key=0xb6696b8 "\001", key_len=3, key_ref_ptr=0xaebbfb7c) at sql_join_cache.cc:2848
#2 0x082da03d in JOIN_CACHE_HASHED::put_record (this=0xb6968d0) at sql_join_cache.cc:2683
#3 0x0831ff99 in sub_select_cache (join=0xb6901b8, join_tab=0xb695cf0, end_of_records=false) at sql_select.cc:13096
#4 0x082d9694 in JOIN_CACHE::generate_full_extensions (this=0xb6967e0,
rec_ptr=0xb68aedb "Unable to render embedded object: File (\330\016) not found.\330\016!\330\016|\241\017\355\244\017#\246\017\062\251\017Ȫ\017\202\254\017N\255\017S\255\017\232\255\017<\260\017\204\260\017İ\017\204\261\017-\262\017|\262\017B\263\017\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245\245h4z\025\217\217\217\217\217", <incomplete sequence \311>) at sql_join_cache.cc:2224
#5 0x082d9456 in JOIN_CACHE::join_matching_records (this=0xb6967e0, skip_last=false) at sql_join_cache.cc:2118
#6 0x082d8fe0 in JOIN_CACHE::join_records (this=0xb6967e0, skip_last=false) at sql_join_cache.cc:1926
#7 0x0831fecf in sub_select_cache (join=0xb6901b8, join_tab=0xb695b1c, end_of_records=true) at sql_select.cc:13083
#8 0x083200e8 in sub_select (join=0xb6901b8, join_tab=0xb695948, end_of_records=true) at sql_select.cc:13245
#9 0x0831f700 in do_select (join=0xb6901b8, fields=0x0, table=0xb68b810, procedure=0x0) at sql_select.cc:12841
#10 0x08303adf in JOIN::exec (this=0xb6901b8) at sql_select.cc:1990
#11 0x08305df4 in mysql_select (thd=0xb62b600, rref_pointer_array=0xb62d07c, tables=0xb667bd8, wild_num=0, fields=..., conds=0x0, og_num=1, order=0xb669018,
group=0x0, having=0x0, proc_param=0x0, select_options=2147764736, result=0xb6690b8, unit=0xb62cce0, select_lex=0xb62cf78) at sql_select.cc:2613
#12 0x082fe4af in handle_select (thd=0xb62b600, lex=0xb62cc84, result=0xb6690b8, setup_tables_done_option=0) at sql_select.cc:277
#13 0x0829b6d4 in execute_sqlcom_select (thd=0xb62b600, all_tables=0xb667bd8) at sql_parse.cc:5081
#14 0x082920b4 in mysql_execute_command (thd=0xb62b600) at sql_parse.cc:2265
#15 0x0829d8b5 in mysql_parse (thd=0xb62b600,
inBuf=0xb667740 "SELECT table2 .`col_date_key` field5 , table2 .`col_int_key` field6 FROM CC table1 STRAIGHT_JOIN ( CC table2 JOIN CC table3 ON table3 .`col_varchar_nokey` ) ON table2 .`col_int_nokey` AND tabl"..., length=286, found_semicolon=0xaebc1230) at sql_parse.cc:6027
#16 0x0828fae6 in dispatch_command (command=COM_QUERY, thd=0xb62b600,
packet=0xb6478f1 " SELECT table2 .`col_date_key` field5 , table2 .`col_int_key` field6 FROM CC table1 STRAIGHT_JOIN ( CC table2 JOIN CC table3 ON table3 .`col_varchar_nokey` ) ON table2 .`col_int_nokey` AND tab"..., packet_length=290) at sql_parse.cc:1184
#17 0x0828ef8c in do_command (thd=0xb62b600) at sql_parse.cc:890
#18 0x0828c0ec in handle_one_connection (arg=0xb62b600) at sql_connect.cc:1153
#19 0x00bea919 in start_thread () from /lib/libpthread.so.0
#20 0x00b2ccbe in clone () from /lib/libc.so.6
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Re: Unkillable queries with JOIN_CACHE_HASHED
This seems to be a memory corruption of some sort. This hang is associated with warnings such as
trial11.log:Error: Memory allocated at sql_join_cache.cc:827 was overrun, discovered at 'ma_pagecache.c:2187'
trial1.log:Error: Memory allocated at (null):0 was underrun, discovered at sql_join_cache.cc:827
trial1.log:Error: Memory allocated at (null):0 was overrun, discovered at 'sql_join_cache.cc:827'
trial1.log:Error: Memory allocated at (null):0 was underrun, discovered at sql_join_cache.cc:827
trial1.log:Error: Memory allocated at (null):0 was overrun, discovered at 'sql_join_cache.cc:827'
Re: Unkillable queries with JOIN_CACHE_HASHED
The hang and the memory corruptions appear to have disappeared.
Launchpad bug id: 663832
Re: Unkillable queries with JOIN_CACHE_HASHED
Let me know if this bug is not fixable based on code inspection and I will provide a test case. Thanks.