| Bug #47367 | Crash in Name_resolution_context::process_error | ||
|---|---|---|---|
| Submitted: | 16 Sep 2009 12:00 | Modified: | 23 Nov 2010 3:01 |
| Reporter: | Matthias Leich | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Optimizer | Severity: | S3 (Non-critical) |
| Version: | 6.0 | OS: | Any |
| Assigned to: | Roy Lyseng | CPU Architecture: | Any |
| Tags: | crash, optimizer_switch, semijoin, subquery | ||
[16 Sep 2009 12:03]
Matthias Leich
The workaround is SET GLOBAL optimizer_switch = 'semijoin=off';
[16 Sep 2009 12:09]
Matthias Leich
Non TEMPORARY tables show the same crash.
[11 Dec 2009 11:47]
Roy Lyseng
Crash occurs because Item_field::fix_after_pullout() replaces the current name resolution context object with a partially initialized one - in particular the error_processor field is not set. The fix seems to be fairly easy: Just copy the old value of error_processor. After this fix, the query delivers an error because of an unknown column, which is correct because the original field has been renamed. However, there are two inherent problems in this treatment: 1. The error message text is reported as "Unknown column f1 in where clause". However, the unknown column is not mentioned in the where clause. This problem occurs because resolving columns during second execution operates on the transformed query, where the select value from the subquery now suddenly has become part of the where clause. 2. With semijoin=off, the query does not fail. This is because the column name f1 will now resolve to a column in the table in the outer query, and the query changes semantical meaning. This behaviour is invalid according to the SQL standard (SELECT clause value expressions should only reference columns in underlying tables, not tables in the outer query context).
[11 Dec 2009 13:49]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/93691 3768 Roy Lyseng 2009-12-11 BUG#47367 Crash in Name_resolution_context::process_error When subquery is transformed into a semijoin, a new name resolution object is assigned for each of the column items of the subquery. The error_processor field of this object was never set, so any error in resolution during second or later execution would cause a crash when this procedure was invoked. mysql-test/r/subselect3.result New test case for bug#47367 mysql-test/r/subselect3_jcl6.result New test case for bug#47367 mysql-test/t/subselect3.test New test case for bug#47367 sql/item.cc Fully initialize the name resolution object when it is created.
[14 Dec 2009 11:39]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/93893 3769 Roy Lyseng 2009-12-14 BUG#47367 Crash in Name_resolution_context::process_error When subquery is transformed into a semijoin, a new name resolution object is assigned for each of the column items of the subquery. The error_processor field of this object was never set, so any error in resolution during second or later execution would cause a crash when this procedure was invoked. mysql-test/r/subselect3.result New test case for bug#47367 mysql-test/r/subselect3_jcl6.result New test case for bug#47367 mysql-test/t/subselect3.test New test case for bug#47367 sql/item.cc Fully initialize the name resolution object when it is created.
[21 Dec 2009 15:39]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20091221153807-80nxoli1tw1z9bxn) (version source revid:roy.lyseng@sun.com-20091214113852-nb7qpsrwa1ekcmyd) (merge vers: 6.0.14-alpha) (pib:15)
[8 Jan 2010 21:21]
Paul DuBois
Noted in 6.0.14 changelog. With semijoin optimization enabled, transformation of a subquery to a semijoin could crash the server if a name resolution error occurred.
[6 May 2010 14:04]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/107668 3136 Roy Lyseng 2010-05-06 BUG#47367 Crash in Name_resolution_context::process_error When subquery is transformed into a semijoin, a new name resolution object is assigned for each of the column items of the subquery. The error_processor field of this object was never set, so any error in resolution during second or later execution would cause a crash when this procedure was invoked. mysql-test/r/subselect3.result New test case for bug#47367 mysql-test/r/subselect3_jcl6.result New test case for bug#47367 mysql-test/t/subselect3.test New test case for bug#47367 sql/item.cc Fully initialize the name resolution object when it is created.
[16 Aug 2010 6:33]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100816062819-bluwgdq8q4xysmlg) (version source revid:alik@sun.com-20100816062612-enatdwnv809iw3s9) (pib:20)
[13 Nov 2010 16:07]
Bugs System
Pushed into mysql-trunk 5.6.99-m5 (revid:alexander.nozdrin@oracle.com-20101113155825-czmva9kg4n31anmu) (version source revid:vasil.dimov@oracle.com-20100629074804-359l9m9gniauxr94) (merge vers: 5.6.99-m4) (pib:21)
[23 Nov 2010 3:01]
Paul DuBois
Bug does not appear in any released 5.6.x version. No 5.6.1 changelog entry needed.
Description: My script: ---------- # The crash disappears if I enable the next statement. # SET SESSION optimizer_switch = 'semijoin=off'; CREATE TEMPORARY TABLE t1 (f1 INTEGER); CREATE TEMPORARY TABLE t2 LIKE t1; delimiter |; CREATE PROCEDURE p1 () BEGIN SELECT f1 FROM t1 WHERE f1 IN (SELECT f1 FROM t2); END| delimiter ;| CALL p1; # Without this ALTER the crash disappears. ALTER TABLE t2 CHANGE COLUMN f1 my_column INT; # This CALL gets a crash. CALL p1; Backtrace from mysql-next-bugfixing 2009-09-16 12:23:16 ------------------------------------------------------- Thread 1 (process 24812): #0 0x00007fd69cdf5ce6 in pthread_kill () from /lib64/libpthread.so.0 #1 0x0000000000b74cd4 in my_write_core (sig=11) at stacktrace.c:309 #2 0x00000000006f3c34 in handle_segfault (sig=11) at mysqld.cc:2755 #3 <signal handler called> #4 0x0000000000627df2 in Name_resolution_context::process_error (this=0x17db290, thd=0x1617218) at item.h:335 #5 0x0000000000620d79 in Item_field::fix_fields (this=0x16301d8, thd=0x1617218, reference=0x17db160) at item.cc:4673 #6 0x000000000064d5d6 in Item_func::fix_fields (this=0x17db0d8, thd=0x1617218, ref=0x1696e88) at item_func.cc:173 #7 0x0000000000662d53 in Item_cond::fix_fields (this=0x1696d70, thd=0x1617218, ref=0x17d7270) at item_cmpfunc.cc:3980 #8 0x0000000000757141 in setup_conds (thd=0x1617218, tables=0x17d9350, leaves=0x17d9350, conds=0x17d7270) at sql_base.cc:7729 #9 0x00000000007b09e1 in setup_without_group (thd=0x1617218, ref_pointer_array=0x17da8f0, tables=0x17d9350, leaves=0x17d9350, fields=@0x162f2a8, all_fields=@0x17d7188, conds=0x17d7270, order=0x0, group=0x0, hidden_group_fields=0x17d7167) at sql_select.cc:453 #10 0x00000000007a6cee in JOIN::prepare (this=0x17d15d0, rref_pointer_array=0x162f388, tables_init=0x17d9350, wild_num=0, conds_init=0x1696d70, og_num=0, order_init=0x0, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x162f1a0, unit_arg=0x162eb10) at sql_select.cc:535 #11 0x00000000007a832a in mysql_select (thd=0x1617218, rref_pointer_array=0x162f388, tables=0x17d9350, wild_num=0, fields=@0x162f2a8, conds=0x1696d70, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147765760, result=0x1696f18, unit=0x162eb10, select_lex=0x162f1a0) at sql_select.cc:3066 #12 0x00000000007adec1 in handle_select (thd=0x1617218, lex=0x162ea70, result=0x1696f18, setup_tables_done_option=0) at sql_select.cc:307 #13 0x0000000000704f7b in execute_sqlcom_select (thd=0x1617218, all_tables=0x17d9350) at sql_parse.cc:4972 #14 0x00000000007068eb in mysql_execute_command (thd=0x1617218) at sql_parse.cc:2121 #15 0x00000000008f6bb1 in sp_instr_stmt::exec_core (this=0x17da670, thd=0x1617218, nextp=0x4034a0f8) at sp_head.cc:2927 #16 0x00000000008f6de1 in sp_lex_keeper::reset_lex_and_exec_core (this=0x17da6b0, thd=0x1617218, nextp=0x4034a0f8, open_tables=false, instr=0x17da670) at sp_head.cc:2752 #17 0x00000000008fd0da in sp_instr_stmt::execute (this=0x17da670, thd=0x1617218, nextp=0x4034a0f8) at sp_head.cc:2865 #18 0x00000000008f9105 in sp_head::execute (this=0x162e350, thd=0x1617218) at sp_head.cc:1249 #19 0x00000000008f9f50 in sp_head::execute_procedure (this=0x162e350, thd=0x1617218, args=0x1619730) at sp_head.cc:1989 #20 0x000000000070d450 in mysql_execute_command (thd=0x1617218) at sql_parse.cc:4430 #21 0x000000000070eedb in mysql_parse (thd=0x1617218, inBuf=0x16f0e30 "CALL p1", length=7, found_semicolon=0x4034bf20) at sql_parse.cc:5987 #22 0x000000000070fb17 in dispatch_command (command=COM_QUERY, thd=0x1617218, packet=0x162a2f9 "CALL p1", packet_length=7) at sql_parse.cc:1074 #23 0x0000000000710fde in do_command (thd=0x1617218) at sql_parse.cc:756 #24 0x00000000006fddf4 in handle_one_connection (arg=0x1617218) at sql_connect.cc:1164 #25 0x00007fd69cdf1040 in start_thread () from /lib64/libpthread.so.0 #26 0x00007fd69bd9208d in clone () from /lib64/libc.so.6 #27 0x0000000000000000 in ?? () Result on mysql-5.1-bugteam 2009-09-16 09:01:28 ----------------------------------------------- no crash + correct results Please note that there are similar looking bugs like Bug#46767 Crash using unknown column name in HAVING clause subquery with materialization (Optimizer options have here also some impact.) but the current bug is IMHO different 1. __assert_rtn is not called Maybe this is to be expected, don't know. 2. I have an ALTER TABLE which renames a column within my script. And the crash disappears without this ALTER. My environment: --------------- - ./BUILD/compile-pentium64-debug-max - Linux OpenSuSE 11.0 (64 Bit) - Intel Core2Duo How to repeat: See above