1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-26 07:02:12 +03:00
Files
mariadb/sql
Oleg Smirnov 69d294e755 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>
2023-11-24 18:30:14 +07:00
..
2020-08-03 14:44:06 +02:00
2021-04-20 12:30:09 +03:00
2022-03-23 10:47:27 +11:00
2020-08-03 13:41:29 +02:00
2020-08-03 14:44:06 +02:00
2021-04-22 07:51:33 +03:00
2021-06-21 12:38:25 +03:00
2020-07-14 22:59:19 +03:00
2023-05-02 10:09:27 +02:00
2021-03-31 09:47:14 +03:00
2020-03-30 14:50:23 +03:00
2020-10-29 13:38:38 +02:00
2021-10-13 12:03:32 +03:00
2020-07-31 18:09:08 +03:00
2020-11-03 14:49:17 +02:00
2023-10-17 14:32:05 +02:00
2020-11-02 15:48:47 +02:00
2021-04-21 07:25:48 +03:00
2020-02-11 14:40:35 +01:00
2020-11-03 14:49:17 +02:00
2020-05-30 11:04:27 +03:00
2022-06-09 11:53:46 +03:00
2021-03-20 13:04:36 +02:00
2022-02-10 20:23:56 +01:00
2020-08-10 18:40:57 +03:00
2020-09-03 09:26:54 +03:00
2021-10-21 14:57:00 +03:00
2020-11-12 15:39:02 +05:30
2021-07-31 22:59:58 +02:00
2023-05-02 10:09:27 +02:00
2022-05-03 10:59:54 +02:00
2022-10-05 10:09:49 +03:00
2021-08-11 23:00:37 +04:00
2022-11-27 05:11:39 +10:00
2023-01-28 18:22:55 +01:00
2021-06-30 18:41:46 +03:00
2022-05-08 23:03:08 +02:00
2020-12-25 09:13:28 +01:00
2023-01-28 18:22:55 +01:00
2021-03-05 10:36:51 +02:00
2021-02-23 09:25:57 +01:00
2021-04-20 12:30:09 +03:00
2022-10-25 10:04:37 +03:00
2020-07-31 18:09:08 +03:00
2022-09-23 13:47:15 +03:00
2020-10-22 13:27:18 +03:00
2022-03-29 11:13:18 +03:00
2020-06-13 15:11:43 +03:00
2020-06-12 10:55:53 +03:00
2023-01-03 16:10:02 +02:00
2020-07-15 09:49:48 +02:00
2020-12-01 14:55:46 +02:00
2020-11-11 07:37:05 +02:00
2022-06-27 10:14:37 +03:00
2020-08-26 11:30:20 +03:00