Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
MDEV-29070 SIGSEGV in my_decimal::operator= and Assertion `0' failed …
…and in Item_type_holder::val_decimal on SELECT The bug is fixed by the patch ported from MySQL. See the comprehensive description below. commit 455c4e8810c76430719b1a08a63ca0f69f44678a Author: Guilhem Bichot <guilhem.bichot@oracle.com> Date: Fri Mar 13 17:51:27 2015 +0100 Bug#17668844: CRASH/ASSERT AT ITEM_TYPE_HOLDER::VAL_STR IN ITEM.C We have a predicate of the form: literal_row <=> (a UNION) The subquery is constant, so Item_cache objects are used for its SELECT list. In order, this happens: - Item_subselect::fix_fields() calls select_lex_unit::prepare, where we create Item_type_holder's (appended to unit->types list), create the tmp table (using type info found in unit->types), and call fill_item_list() to put the Item_field's of this table into unit->item_list. - Item_subselect::fix_length_and_dec() calls set_row() which makes Item_cache's of the subquery wrap the Item_type_holder's - When/if a first result row is found for the subquery, Item_cache's are re-pointed to unit->item_list (i.e. Item_field objects which reference the UNION's tmp table columns) (see call to Item_singlerow_subselect::store()). - In our subquery, no result row is found, so the Item_cache's still wrap Item_type_holder's; evaluating '<=>' reads the value of those, but Item_type_holder objects are not expected to be evaluated. Fix: instead of putting unit->types into Item_cache, and later replacing with unit->item_list, put unit->item_list in Item_cache from the start. Approved by Oleksandr Byelkin <sanja@mariadb.com>
- Loading branch information
1 parent
85f2e4f
commit 69d294e
Showing
8 changed files
with
286 additions
and
8 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters