| Bug #24056 | subselect.test fails in 5.0-opt on 64 bit platforms after fix for BUG#8804 | ||
|---|---|---|---|
| Submitted: | 7 Nov 2006 18:42 | Modified: | 9 Dec 2006 18:23 |
| Reporter: | Sergey Petrunya | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Optimizer | Severity: | S3 (Non-critical) |
| Version: | OS: | ||
| Assigned to: | Sergey Petrunya | CPU Architecture: | Any |
| Tags: | Optimizer, subquery, test failure | ||
[7 Nov 2006 18:42]
Sergey Petrunya
[7 Nov 2006 18:43]
Sergey Petrunya
Running with valgrind on 32 bit produces no errors.
[7 Nov 2006 19:39]
Sergey Petrunya
Analysis:
It seems to be impossible to construct a simple test case - the problem
disappears if one omits a significant part of the .test file preceding the
problematic query.
The problem occurs here:
sql_select.cc:
DBUG_ENTER("get_best_combination");
table_count=join->tables;
if (!(join->join_tab=join_tab=
(JOIN_TAB*) thd->alloc(sizeof(JOIN_TAB)*table_count)))
DBUG_RETURN(TRUE);
Here thd->alloc() returns a pointer that clearly is a garbage value.
This seems to happen because of MEM_ROOT structures corruption: tracing the
above thd->alloc() call shows the following:
gptr alloc_root(MEM_ROOT *mem_root,unsigned int Size)
...
>> point= (gptr) ((char*) next+ (next->size-next->left));
/*TODO: next part may be unneded due to mem_root->first_block_usage counter*/
if ((next->left-= Size) < mem_root->min_malloc)
{ /* Full block */
...
Here we have:
(gdb) p *next
$14 = {next = 0x0, left = 73300, size = 8132}
i.e. memory block size is 8132 of which 73300 bytes are 'free'. Apparently
MEM_ROOT structure got corrupted somewhere.
Here is the full stack trace of the above locations:
#0 alloc_root (...)
#1 0x000000000055aef3 in Query_arena::alloc (...)
#2 0x000000000066d5db in get_best_combination (...)
#3 0x00000000006677c8 in make_join_statistics (...)
#4 0x000000000066182c in JOIN::optimize (...)
#5 0x00000000005cefcf in subselect_single_select_engine::exec (...)
#6 0x00000000005cabd0 in Item_subselect::exec (...)
#7 0x00000000005cc6bb in Item_in_subselect::val_bool (...)
#8 0x0000000000575d56 in Item::val_bool_result (...)
#9 0x000000000059d912 in Item_in_optimizer::val_int (...)
#10 0x000000000055e570 in Item::val_bool (...)
#11 0x000000000059b600 in Item_func_not::val_int (...)
#12 0x00000000006797be in evaluate_join_record (...)
#13 0x0000000000679653 in sub_select (...)
#14 0x00000000006791ea in do_select (...)
#15 0x000000000066561e in JOIN::exec (...)
#16 0x0000000000665bd6 in mysql_select (...)
#17 0x0000000000660174 in handle_select (...)
#18 0x00000000006208a9 in mysql_execute_command (...)
#19 0x00000000006291a5 in mysql_parse (...)
#20 0x000000000061e8e9 in dispatch_command (...)
#21 0x000000000061dfb3 in do_command (...)
#22 0x000000000061d13e in handle_one_connection (...)
#23 0x00002aaaaaef9a4f in pthread_start_thread (...)
#24 0x00002aaaaaef9af3 in pthread_start_thread_event (...)
#25 0x00002aaaab50c513 in clone (...)
[7 Nov 2006 23:17]
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/15001 ChangeSet@1.2300, 2006-11-08 02:26:50+03:00, sergefp@mysql.com +1 -0 BUG#24056: Crash in subquery: Don't assume that condition that was pushed down into subquery has produced exactly one KEY_FIELD element - it could produce several or none at all, handle all of those cases.
[27 Nov 2006 17:16]
Georgi Kodinov
Pushed in 5.0.32/5.1.14-beta
[9 Dec 2006 18:23]
Paul DuBois
Noted in 5.0.32, 5.1.14 changelogs. Subqueries for which a pushed-down condition did not produce exactly one key field could cause a server crash.
