database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-07-30 16:24:05 +03:00
Code Activity

Bug#19941403: FATAL_SIGNAL(SIG 6) IN BUILD_EQUAL_ITEMS_FOR_COND | IN SQL/SQL_OPTIMIZER.CC:1657

Browse Source 
Problem:
At the end of first execution select_lex->prep_where is pointing to
a runtime created object (temporary table field). As a result
server exits trying to access a invalid pointer during second
execution.

Analysis:
While optimizing the join conditions for the query, after the
permanent transformation, optimizer makes a copy of the new
where conditions in select_lex->prep_where. "prep_where" is what
is used as the "where condition" for the query at the start of execution.
W.r.t the query in question, "where" condition is actually pointing
to a field in the temporary table. As a result, for the  second
execution the pointer is no more valid resulting in server exit.

Fix:
At the end of the first execution, select_lex->where will have the
original item of the where condition.
Make prep_where the new place where the original item of select->where
has to be rolled back.
Fixed in 5.7 with the wl#7082 - Move permanent transformations from
JOIN::optimize to JOIN::prepare

Patch for 5.5 includes the following backports from 5.6:

Bugfix for Bug12603141 - This makes the first execute statement in the testcase
pass in 5.5

However it was noted later in in Bug16163596 that the above bugfix needed to
be modified. Although Bug16163596 is reproducible only with changes done for
Bug12582849, we have decided include the fix.

Considering that Bug12582849 is related to Bug12603141, the fix is
also included here. However this results in Bug16317817, Bug16317685,
Bug16739050. So fix for the above three bugs is also part of this patch.
This commit is contained in:
Chaithra Gopalareddy
2015-11-20 12:30:15 +05:30
parent f3554bf148
commit a7fb5aecfd
8 changed files with 85 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
sql/sql_lex.cc
View File

@ -1,5 +1,5 @@
/*
Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.
Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
@ -3158,7 +3158,26 @@ void st_select_lex::fix_prepare_information(THD *thd, Item **conds,
}
if (*conds)
{
prep_where= *conds;
/*
In "WHERE outer_field", *conds may be an Item_outer_ref allocated in
the execution memroot.
@todo change this line in WL#7082. Currently, when we execute a SP,
containing "SELECT (SELECT ... WHERE t1.col) FROM t1",
resolution may make *conds equal to an Item_outer_ref, then below
*conds becomes Item_field, which then goes straight on to execution,
undoing the effects of putting Item_outer_ref in the first place...
With a PS the problem is not as severe, as after the code below we
don't go to execution: a next execution will do a new name resolution
which will create Item_outer_ref again.
To reviewers: in WL#7082,
prep_where= (*conds)->real_item();
becomes:
prep_where= *conds;
thd->change_item_tree_place(conds, &prep_where);
and same for HAVING.
*/
prep_where= (*conds)->real_item();
*conds= where= prep_where->copy_andor_structure(thd);
}
if (*having_conds)