Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
5.5.59, 10.0.33, 10.1.28, 10.1.30, 10.2.12, 10.3.4
-
None
Description
Query of the form
select ...
|
from some_table
|
where some_table.id in (select distinct other_table.id
|
from other_table
|
where (other_table.val1 = '23' or other_table.val2 ='42')
|
and other_table.val3 is null
|
)
|
crashes with backtrace:
.../mysqld(my_print_stacktrace+0x2b) [0x7fbd68549d6b]
|
.../mysqld(handle_fatal_signal+0x4d5) [0x7fbd680a7f75]
|
/lib64/libpthread.so.0(+0x36ef60f7e0) [0x7fbd676a17e0]
|
.../mysqld(Item_func::fix_fields(THD*, Item**)+0x86) [0x7fbd680fb186]
|
.../mysqld(Item_cond::fix_fields(THD*, Item**)+0xef) [0x7fbd680d436f]
|
.../mysqld(setup_conds(THD*, TABLE_LIST*, List<TABLE_LIST>&, Item**)+0x19b) [0x7fbd67ef1a8b]
|
.../mysqld(JOIN::prepare(Item***, TABLE_LIST*, unsigned int, Item*, unsigned int, st_order*, bool, st_order*, Item*, st_order*, st_select_lex*, st_select_lex_unit*)+0x426) [0x7fbd67f77246]
|
.../mysqld(mysql_select(THD*, Item***, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*)+0x946) [0x7fbd67f85ea6]
|
.../mysqld(handle_select(THD*, LEX*, select_result*, unsigned long)+0x265) [0x7fbd67f88fe5]
|
.../mysqld(+0x456432) [0x7fbd67f28432]
|
.../mysqld(mysql_execute_command(THD*)+0x68de) [0x7fbd67f356fe]
|
.../mysqld(Prepared_statement::execute(String*, bool)+0x4ba) [0x7fbd67f4886a]
|
.../mysqld(+0x4792dc) [0x7fbd67f4b2dc]
|
.../mysqld_stmt_execute(THD*, char*, unsigned int)+0x18e) [0x7fbd67f4b9de]
|
.../mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int)+0xe30) [0x7fbd67f39480]
|
.../mysqld(do_command(THD*)+0x13e) [0x7fbd67f3aebe]
|
.../mysqld(do_handle_one_connection(THD*)+0x17f) [0x7fbd67ffb74f]
|
.../mysqld(handle_one_connection+0x47) [0x7fbd67ffb887]
|
(Most of the time it actually crashed with useless backtrace only starting at handle_fatal_signal, so there seems to be some stack overwrite involved)
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
-
- Open
-
-
-
- Closed
-
Activity
but above Items (2 of them created - one during prepare, and one during execution) put in statement memory so they are not removed.
"Normal" execution is based on hack (first bug) that direct view reference put in statement memory and can be used without re-prepare.
It this scenario QC answer instead first execution but statement marked as it was really first time executed (second bug) so direct view reference was put in runtime memory during real first execution and so can not be used after that.
in 5.5 we will fix only bug with incorrect first execution flag, for view references created https://jira.mariadb.org/browse/MDEV-15614
revision-id: 49a443c53a7f01812299f20e94c7209579efd881 (mariadb-5.5.59-45-g49a443c53a7)
parent(s): 0943b33de3daa0fcbf58803be8e991941de63218
author: Oleksandr Byelkin
committer: Oleksandr Byelkin
timestamp: 2018-03-21 12:13:37 +0100
message:
MDEV-15492: Subquery crash similar to MDEV-10050
Detection of first execution of PS fixed.
More debug info.
—
in "Normal" execution there is also Item_direct_view_ref used in the right part of semijoin.