[MDEV-18675] Server crashes in COND_EQUAL::copy Created: 2019-02-21  Updated: 2019-04-04  Resolved: 2019-04-04

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.4
Fix Version/s: 10.4.4

Type: Bug Priority: Major
Reporter: Alice Sherepa Assignee: Galina Shalygina (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
PartOf
is part of MDEV-18769 Assertion `fixed == 1' failed in Item... Closed
Problem/Incident
is caused by MDEV-7486 Condition pushdown from HAVING into W... Closed

 Description   

Reproducible on 10.4 with MyIsam/Innodb

set optimizer_switch='condition_pushdown_from_having=on';
CREATE TABLE t1 (id int);
CREATE TABLE t2 (pk int, v varchar(1));
 
SELECT t2.pk
FROM (t2, t2 AS dtb, t1)
WHERE t1.id = 3 OR t2.v = dtb.v AND (t2.pk = 212 AND t2.pk = 95)
GROUP BY t2.pk 
HAVING t2.pk = 'x';

10.4 4932aba921755cfbc35

#3  <signal handler called>
#4  0x00005561099bb66d in COND_EQUAL::copy (this=0x0, cond_equal=...) at /10.4/sql/item_cmpfunc.h:3237
#5  0x0000556109b03611 in and_new_conditions_to_optimized_cond (thd=0x7fbd50000a98, cond=0x7fbd50060000, cond_eq=0x7fbd5005f318, new_conds=..., cond_value=0x7fbd5005f1b0, build_cond_equal=true) at /10.4/sql/opt_subselect.cc:5775
#6  0x000055610996edc7 in JOIN::optimize_inner (this=0x7fbd5005ee70) at /10.4/sql/sql_select.cc:1896
#7  0x000055610996d6fe in JOIN::optimize (this=0x7fbd5005ee70) at /10.4/sql/sql_select.cc:1508
#8  0x00005561099786c6 in mysql_select (thd=0x7fbd50000a98, tables=0x7fbd50139bf0, wild_num=0, fields=..., conds=0x7fbd5014a4d0, og_num=1, order=0x0, group=0x7fbd50018360, having=0x7fbd50149e80, proc_param=0x0, select_options=2147748608, result=0x7fbd5013ea00, unit=0x7fbd500049a8, select_lex=0x7fbd50147970) at /10.4/sql/sql_select.cc:4518
#9  0x0000556109969072 in handle_select (thd=0x7fbd50000a98, lex=0x7fbd500048e0, result=0x7fbd5013ea00, setup_tables_done_option=0) at /10.4/sql/sql_select.cc:423
#10 0x0000556109931990 in execute_sqlcom_select (thd=0x7fbd50000a98, all_tables=0x7fbd50139bf0) at /10.4/sql/sql_parse.cc:6588
#11 0x0000556109926841 in mysql_execute_command (thd=0x7fbd50000a98) at /10.4/sql/sql_parse.cc:3825
#12 0x00005561099358f7 in mysql_parse (thd=0x7fbd50000a98, rawbuf=0x7fbd50141340 "SELECT t2.pk\nFROM (t2, t2 AS dtb, t1)\nWHERE t1.id = 3 OR t2.v = dtb.v AND (t2.pk = 212 AND t2.pk = 95)\nGROUP BY t2.pk \nHAVING t2.pk = 'x'", length=137, parser_state=0x7fbd994a9060, is_com_multi=false, is_next_command=false) at /10.4/sql/sql_parse.cc:8141
#13 0x0000556109920b98 in dispatch_command (command=COM_QUERY, thd=0x7fbd50000a98, packet=0x7fbd50009af9 "SELECT t2.pk\nFROM (t2, t2 AS dtb, t1)\nWHERE t1.id = 3 OR t2.v = dtb.v AND (t2.pk = 212 AND t2.pk = 95)\nGROUP BY t2.pk \nHAVING t2.pk = 'x'", packet_length=137, is_com_multi=false, is_next_command=false) at /10.4/sql/sql_parse.cc:1820
#14 0x000055610991f3e8 in do_command (thd=0x7fbd50000a98) at /10.4/sql/sql_parse.cc:1358
#15 0x0000556109a9abc5 in do_handle_one_connection (connect=0x55610c4f0208) at /10.4/sql/sql_connect.cc:1399
#16 0x0000556109a9a903 in handle_one_connection (arg=0x55610c4f0208) at /10.4/sql/sql_connect.cc:1302
#17 0x000055610a4247fd in pfs_spawn_thread (arg=0x55610c424738) at /10.4/storage/perfschema/pfs.cc:1862
#18 0x00007fbda1e196ba in start_thread (arg=0x7fbd994aa700) at pthread_create.c:333
#19 0x00007fbda10aa41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109



 Comments   
Comment by Galina Shalygina (Inactive) [ 2019-03-14 ]

This bug appears because copy() method is called for the empty object (empty COND_EQUAL).

Consider conds from the example above:

t1.id = 3 OR t2.v = dtb.v AND (t2.pk = 212 AND t2.pk = 95)

It can be seen that the right part of the OR condition is always false. So after optimize_cond() work it will be deleted from conds.

COND_EQUAL for conds is built in build_item_equal() method. For OR condition it remains empty.

After build_item_equal() call remove_eq_conds() is called. It deletes always false right part of the OR condition of conds.

So conds after optimize_cond() is looking as:

multiple equal(3, t1.`id`)

COND_EQUAL for conds should contain conds itself but it remains empty.

COND_EQUAL should be set after remove_eq_conds(). Now COND_EQUAL is set only for the similar case when only one part of OR condition remains and it is AND condition.

Thу case of this bug when only one part of OR condition remains and it is multiple equality is missing.

To fix it COND_EQUAL for this case should be set after remove_eq_conds() call.

Comment by Galina Shalygina (Inactive) [ 2019-04-04 ]

Fixed in MDEV-18769

Generated at Thu Feb 08 08:45:53 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.