[MDEV-22464] Server crash on UPDATE with nested subquery Created: 2020-05-05  Updated: 2021-10-11  Resolved: 2021-10-11

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Update
Affects Version/s: 10.5.2, 10.3, 10.4, 10.5, 10.6
Fix Version/s: 10.3.32, 10.4.22, 10.5.13, 10.6.5

Type: Bug Priority: Critical
Reporter: Yongheng Chen Assignee: Aleksey Midenkov
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates MDEV-26160 crash/valgrind error in resolve_ref_i... Closed
is duplicated by MDEV-22476 Crash bug in update-related functions... Closed
is duplicated by MDEV-25637 Bug report: abortion in sql/set_var.cc:0 Closed
is duplicated by MDEV-26415 MariaDB server crash in Used_tables_a... Closed
Relates
relates to MDEV-16549 Server crashes in Item_field::fix_fie... Closed

 Description   

Server crashes in Item_ref::fix_fields/Item::fix_fields_if_needed, assertion `*ref && (*ref)->fixed()' failed in Item_ref::fix_fields

We found a memory corruption bug that crash the debug build of mariadb.

POC:

CREATE TABLE v0 ( v1 INT ) ;
INSERT INTO v0 ( v1 ) VALUES ( 60 ) ; 
UPDATE v0 SET v1 = NULL BETWEEN ( SELECT 95 FROM v0 WHERE v1 = 95 AND v1 < -1 GROUP BY - 'x' >= v1 HAVING ( -128 = 2147483647 AND v1 = 94 ) ) AND 36 WHERE v1 = 2 ;

Stack dump:

200505  5:53:28 [ERROR] mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
 
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
 
Server version: 10.5.3-MariaDB-debug
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=3
max_threads=153
thread_count=4
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467925 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x7f32b8000d78
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7f32f8ea9dc0 thread_stack 0x49000
fil/fil0fil.cc:3410(fil_ibd_discover(unsigned long, Datafile&))[0x32d4681]
sql/multi_range_read.cc:764(Mrr_ordered_index_reader::refill_buffer(bool))[0x13c0898]
??:0(__restore_rt)[0x7f331352b890]
sql/sql_list.h:696(Ack_receiver::~Ack_receiver())[0x147a8e0]
sql/sql_bitmap.h:78(TABLE::prune_range_rowid_filters())[0x1570027]
sql/field.h:3573(Field_time_with_dec::Field_time_with_dec(unsigned char*, unsigned char*, unsigned char, Field::utype, st_mysql_const_lex_string const*, unsigned int))[0x14fa4b4]
psi/mysql_thread.h:738(inline_mysql_mutex_lock(st_mysql_mutex*, char const*, unsigned int))[0xaf14d0]
sql-common/client.c:1103(cli_fetch_lengths)[0x16bb78b]
sql/sql_yacc_ora.yy:2919(ORAparse(THD*))[0x168f4ba]
sql/sql_bitmap.h:78(TABLE::prune_range_rowid_filters())[0x1570027]
/usr/local/mysql/bin/mysqld(_Z12setup_fieldsP3THD20Bounds_checked_arrayIP4ItemER4ListIS2_E17enum_column_usagePS6_S9_b+0x864)[0x84aa74]
sql/sql_lex.cc:6312(LEX::sp_variable_declarations_copy_type_finalize(THD*, int, Column_definition const&, Row_definition_list*, Item*))[0xd908a2]
sql/slave.cc:4171(apply_event_and_update_pos_for_parallel(Log_event*, THD*, rpl_group_info*))[0xaf4a5d]
sql/sql_alloc.h:39(show_master_info_get_fields(THD*, List<Item>*, bool, unsigned long))[0xae3e76]
sql/item.h:3609(Item_null::Item_null(THD*, char const*, charset_info_st const*))[0xd8f934]
handler/i_s.cc:312(__cxx_global_var_init.15)[0xa25a6b]
sql/sys_vars.ic:627(Sys_var_charptr_fscs::Sys_var_charptr(char const*, char const, int, long, unsigned long, CMD_LINE, char const, PolyLock*, sys_var::binlog_status_enum, bool (*)(PolyLock**, THD*, set_var*), bool (*)(sys_var::binlog_status_enum, THD, enum_var_type), char const))[0xa07b70]
sql/set_var.h:258(_GLOBAL__sub_I_sys_vars.cc)[0x9fd70e]
sql/sys_vars.cc:5730(__cxx_global_var_init.1236)[0xa099cb]
sql/item.h:4563(Item_empty_string::Item_empty_string(THD*, char const*, unsigned int, charset_info_st const*))[0xedb6d1]
sql/item.h:746(show_binlog_info_get_fields(THD*, List<Item>*))[0xedaec1]
gcalc_slicescan.cc:0(__afl_fork_wait_loop)[0x1e8dfc6]
nptl/pthread_create.c:463(start_thread)[0x7f33135206db]
x86_64/clone.S:97(clone)[0x7f33112c088f]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f32b8015055): UPDATE v0 SET v1 = NULL BETWEEN ( SELECT 95 FROM v0 WHERE v1 = 95 AND v1 < -1 GROUP BY - 'x' >= v1 HAVING ( -128 = 2147483647 AND v1 = 94 ) ) AND 36 WHERE v1 = 2
Connection ID (thread ID): 7521
Status: NOT_KILLED
 
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off
 
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /usr/local/mysql/data
Resource Limits:
Limit                     Soft Limit           Hard Limit           Units
Max cpu time              unlimited            unlimited            seconds
Max file size             unlimited            unlimited            bytes
Max data size             unlimited            unlimited            bytes
Max stack size            8388608              unlimited            bytes
Max core file size        unlimited            unlimited            bytes
Max resident set          unlimited            unlimited            bytes
Max processes             unlimited            unlimited            processes
Max open files            1048576              1048576              files
Max locked memory         16777216             16777216             bytes
Max address space         unlimited            unlimited            bytes
Max file locks            unlimited            unlimited            locks
Max pending signals       1030951              1030951              signals
Max msgqueue size         819200               819200               bytes
Max nice priority         0                    0
Max realtime priority     0                    0
Max realtime timeout      unlimited            unlimited            us
Core pattern: co...
---



 Comments   
Comment by Marko Mäkelä [ 2020-05-05 ]

An optimized debug build crashes for me like this:

10.5 64488a6f2dd6aa43462292b757e783cfba11a8c6

Thread 1 (Thread 0x7fac3edb2700 (LWP 1017876)):
#0  __pthread_kill (threadid=<optimized out>, signo=11) at ../sysdeps/unix/sysv/linux/pthread_kill.c:56
#1  0x00005587347553a7 in handle_fatal_signal (sig=11) at /mariadb/10.5-merge/sql/signal_handler.cc:329
#2  <signal handler called>
#3  0x0000558734783254 in Item_ref::fix_fields (this=0x7fac28015640, thd=0x7fac28000d48, reference=<optimized out>) at /mariadb/10.5-merge/sql/item.cc:7772
#4  0x00005587347c6916 in Item::fix_fields_if_needed (this=0x7fac28015640, thd=0x7fac28000d48, ref=0x7fac280158a0) at /mariadb/10.5-merge/sql/item.h:976
#5  Item_func::fix_fields (this=0x7fac28015808, thd=0x7fac28000d48, ref=<optimized out>) at /mariadb/10.5-merge/sql/item_func.cc:352
#6  0x00005587347a4005 in Item::fix_fields_if_needed (this=0x7fac28015808, thd=0x7fac28000d48, ref=0x7fac28015b88) at /mariadb/10.5-merge/sql/item.h:976
#7  Item::fix_fields_if_needed_for_scalar (this=0x7fac28015808, thd=0x7fac28000d48, ref=0x7fac28015b88) at /mariadb/10.5-merge/sql/item.h:980
#8  Item::fix_fields_if_needed_for_bool (this=0x7fac28015808, thd=0x7fac28000d48, ref=0x7fac28015b88) at /mariadb/10.5-merge/sql/item.h:984
#9  Item_cond::fix_fields (this=0x7fac28015a50, thd=<optimized out>, ref=<optimized out>) at /mariadb/10.5-merge/sql/item_cmpfunc.cc:4875
#10 0x00005587345238b0 in Item::fix_fields_if_needed (this=0x7fac28015a50, thd=0x7fac28000d48, ref=0x7fac28017800) at /mariadb/10.5-merge/sql/item.h:976
#11 Item::fix_fields_if_needed_for_scalar (this=0x7fac28015a50, thd=0x7fac28000d48, ref=0x7fac28017800) at /mariadb/10.5-merge/sql/item.h:980
#12 Item::fix_fields_if_needed_for_bool (this=0x7fac28015a50, thd=0x7fac28000d48, ref=0x7fac28017800) at /mariadb/10.5-merge/sql/item.h:984
#13 JOIN::prepare (this=0x7fac28017650, tables_init=<optimized out>, conds_init=<optimized out>, og_num=<optimized out>, order_init=<optimized out>, skip_order_by=<optimized out>, group_init=<optimized out>, having_init=<optimized out>, proc_param_init=<optimized out>, select_lex_arg=<optimized out>, unit_arg=<optimized out>) at /mariadb/10.5-merge/sql/sql_select.cc:1287
#14 0x000055873482736e in subselect_single_select_engine::prepare (this=<optimized out>, thd=0x7fac28000d48) at /mariadb/10.5-merge/sql/item_subselect.cc:3722
#15 0x000055873481c20b in Item_subselect::fix_fields (this=0x7fac280163a0, thd_param=0x7fac28000d48, ref=0x7fac28016780) at /mariadb/10.5-merge/sql/item_subselect.cc:285
#16 0x00005587347c6916 in Item::fix_fields_if_needed (this=0x7fac280163a0, thd=0x7fac28000d48, ref=0x7fac28016780) at /mariadb/10.5-merge/sql/item.h:976
#17 Item_func::fix_fields (this=0x7fac28016628, thd=0x7fac28000d48, ref=<optimized out>) at /mariadb/10.5-merge/sql/item_func.cc:352
#18 0x000055873447526c in Item::fix_fields_if_needed (this=0x7fac28016628, thd=0x7fac28000d48, ref=0x7fac280167a8) at /mariadb/10.5-merge/sql/item.h:976
#19 Item::fix_fields_if_needed_for_scalar (this=0x7fac28016628, thd=0x7fac28000d48, ref=0x7fac280167a8) at /mariadb/10.5-merge/sql/item.h:980
#20 setup_fields (thd=0x7fac28000d48, ref_pointer_array=..., fields=..., column_usage=<optimized out>, sum_func_list=0x0, pre_fix=0x0, allow_sum_func=<optimized out>) at /mariadb/10.5-merge/sql/sql_base.cc:7516
#21 0x00005587345c6067 in multi_update::prepare (this=0x7fac28016dd0, not_used_values=..., lex_unit=<optimized out>) at /mariadb/10.5-merge/sql/sql_update.cc:2020
#22 0x000055873452432e in JOIN::prepare (this=0x7fac28016ea8, tables_init=<optimized out>, conds_init=<optimized out>, og_num=<optimized out>, order_init=<optimized out>, skip_order_by=<optimized out>, group_init=<optimized out>, having_init=<optimized out>, proc_param_init=<optimized out>, select_lex_arg=<optimized out>, unit_arg=<optimized out>) at /mariadb/10.5-merge/sql/sql_select.cc:1485
#23 0x000055873451fc10 in mysql_select (thd=0x7fac28000d48, tables=0x7fac28012ec0, fields=..., conds=<optimized out>, og_num=<optimized out>, order=<optimized out>, group=<optimized out>, having=<optimized out>, proc_param=<optimized out>, select_options=<optimized out>, result=<optimized out>, unit=<optimized out>, select_lex=<optimized out>) at /mariadb/10.5-merge/sql/sql_select.cc:4633
#24 0x00005587345c5c34 in mysql_multi_update (thd=0x7fac28000d48, table_list=0x7fac28012ec0, fields=<optimized out>, values=<optimized out>, conds=0x7fac28016998, options=0, handle_duplicates=DUP_ERROR, ignore=<optimized out>, unit=0x7fac28004d58, select_lex=0x7fac28005558, result=0x7fac3edb11d0) at /mariadb/10.5-merge/sql/sql_update.cc:1923
#25 0x00005587344ee92c in mysql_execute_command (thd=0x7fac28000d48) at /mariadb/10.5-merge/sql/sql_parse.cc:4439
#26 0x00005587344e83ad in mysql_parse (thd=0x7fac28000d48, rawbuf=0x7fac28012cd0 "UPDATE v0 SET v1 = NULL BETWEEN ( SELECT 95 FROM v0 WHERE v1 = 95 AND v1 < -1 GROUP BY - 'x' >= v1 HAVING ( -128 = 2147483647 AND v1 = 94 ) ) AND 36 WHERE v1 = 2", length=<optimized out>, parser_state=<optimized out>, is_com_multi=<optimized out>, is_next_command=<optimized out>) at /mariadb/10.5-merge/sql/sql_parse.cc:7957
#27 0x00005587344e4d7e in dispatch_command (command=COM_QUERY, thd=0x7fac28000d48, packet=0x7fac281abaa9 "UPDATE v0 SET v1 = NULL BETWEEN ( SELECT 95 FROM v0 WHERE v1 = 95 AND v1 < -1 GROUP BY - 'x' >= v1 HAVING ( -128 = 2147483647 AND v1 = 94 ) ) AND 36 WHERE v1 = 2 ", packet_length=162, is_com_multi=false, is_next_command=false) at /mariadb/10.5-merge/sql/sql_parse.cc:1839
#28 0x00005587344e8bc9 in do_command (thd=0x7fac28000d48) at /mariadb/10.5-merge/sql/sql_parse.cc:1358
#29 0x0000558734619de9 in do_handle_one_connection (connect=<optimized out>, put_in_cache=<optimized out>) at /mariadb/10.5-merge/sql/sql_connect.cc:1422
#30 0x0000558734619c25 in handle_one_connection (arg=0x558738121f58) at /mariadb/10.5-merge/sql/sql_connect.cc:1319
#31 0x00005587349ffa4f in pfs_spawn_thread (arg=0x55873806a5b8) at /mariadb/10.5-merge/storage/perfschema/pfs.cc:2201
#32 0x00007fac48fbaf27 in start_thread (arg=<optimized out>) at pthread_create.c:479
#33 0x00007fac486002ef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

However, a cmake -DWITH_ASAN=ON build would not crash, and it would instead report an error:

10.5 64488a6f2dd6aa43462292b757e783cfba11a8c6

CURRENT_TEST: main.poc
mysqltest: At line 3: query 'UPDATE v0 SET v1 = NULL BETWEEN ( SELECT 95 FROM v0 WHERE v1 = 95 AND v1 < -1 GROUP BY - 'x' >= v1 HAVING ( -128 = 2147483647 AND v1 = 94 ) ) AND 36 WHERE v1 = 2 ' failed: 1247: Reference 'v1' not supported (forward reference in item list)

This might be due to uninitialized memory. I did not try WITH_MSAN (MDEV-20377) or Valgrind.

Comment by Alice Sherepa [ 2020-05-05 ]

Thanks! Repeatable on MariaDB 10.3-10.5:

create table t1 (a int) ;
insert into t1 (a) values (1),(2),(3) ; 
 
update t1 set a= (select 2 from t1 having (a = 3));

10.3 ec9908b2577758ffb3c

#3  <signal handler called>
#4  0x0000563b26a88d15 in Item_ref::fix_fields (this=0x7fd7d0014610, thd=0x7fd7d0000d50, reference=0x7fd7d0014838) at /10.3/sql/item.cc:7949
#5  0x0000563b2663f55c in Item::fix_fields_if_needed (this=0x7fd7d0014610, thd=0x7fd7d0000d50, ref=0x7fd7d0014838) at /10.3/sql/item.h:823
#6  0x0000563b26ada647 in Item_func::fix_fields (this=0x7fd7d00147a8, thd=0x7fd7d0000d50, ref=0x7fd7d00155b8) at /10.3/sql/item_func.cc:352
#7  0x0000563b2663f55c in Item::fix_fields_if_needed (this=0x7fd7d00147a8, thd=0x7fd7d0000d50, ref=0x7fd7d00155b8) at /10.3/sql/item.h:823
#8  0x0000563b2663f589 in Item::fix_fields_if_needed_for_scalar (this=0x7fd7d00147a8, thd=0x7fd7d0000d50, ref=0x7fd7d00155b8) at /10.3/sql/item.h:827
#9  0x0000563b266bd9ed in Item::fix_fields_if_needed_for_bool (this=0x7fd7d00147a8, thd=0x7fd7d0000d50, ref=0x7fd7d00155b8) at /10.3/sql/item.h:831
#10 0x0000563b26786e55 in JOIN::prepare (this=0x7fd7d0015408, tables_init=0x7fd7d0013f98, wild_num=0, conds_init=0x0, og_num=0, order_init=0x0, skip_order_by=false, group_init=0x0, having_init=0x7fd7d00147a8, proc_param_init=0x0, select_lex_arg=0x7fd7d0013318, unit_arg=0x7fd7d0013730) at /10.3/sql/sql_select.cc:1184
#11 0x0000563b26b39974 in subselect_single_select_engine::prepare (this=0x7fd7d0014a98, thd=0x7fd7d0000d50) at /10.3/sql/item_subselect.cc:3683
#12 0x0000563b26b2c85d in Item_subselect::fix_fields (this=0x7fd7d0014910, thd_param=0x7fd7d0000d50, ref=0x7fd7d0014af0) at /10.3/sql/item_subselect.cc:276
#13 0x0000563b2663f55c in Item::fix_fields_if_needed (this=0x7fd7d0014910, thd=0x7fd7d0000d50, ref=0x7fd7d0014af0) at /10.3/sql/item.h:823
#14 0x0000563b2663f589 in Item::fix_fields_if_needed_for_scalar (this=0x7fd7d0014910, thd=0x7fd7d0000d50, ref=0x7fd7d0014af0) at /10.3/sql/item.h:827
#15 0x0000563b266b807c in setup_fields (thd=0x7fd7d0000d50, ref_pointer_array=..., fields=..., column_usage=MARK_COLUMNS_READ, sum_func_list=0x0, pre_fix=0x0, allow_sum_func=false) at /10.3/sql/sql_base.cc:7456
#16 0x0000563b26849135 in multi_update::prepare (this=0x7fd7d0014cd8, not_used_values=..., lex_unit=0x7fd7d0004c18) at /10.3/sql/sql_update.cc:1896
#17 0x0000563b26787b7d in JOIN::prepare (this=0x7fd7d0014db0, tables_init=0x7fd7d0012b90, wild_num=0, conds_init=0x0, og_num=0, order_init=0x0, skip_order_by=false, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x7fd7d00053a0, unit_arg=0x7fd7d0004c18) at /10.3/sql/sql_select.cc:1376
#18 0x0000563b26792154 in mysql_select (thd=0x7fd7d0000d50, tables=0x7fd7d0012b90, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=1342177408, result=0x7fd7d0014cd8, unit=0x7fd7d0004c18, select_lex=0x7fd7d00053a0) at /10.3/sql/sql_select.cc:4279
#19 0x0000563b26848b42 in mysql_multi_update (thd=0x7fd7d0000d50, table_list=0x7fd7d0012b90, fields=0x7fd7d00054c8, values=0x7fd7d00059d0, conds=0x0, options=0, handle_duplicates=DUP_ERROR, ignore=false, unit=0x7fd7d0004c18, select_lex=0x7fd7d00053a0, result=0x7fd7ec3a7fa0) at /10.3/sql/sql_update.cc:1799
#20 0x0000563b26743ae2 in mysql_execute_command (thd=0x7fd7d0000d50) at /10.3/sql/sql_parse.cc:4369
#21 0x0000563b2674f996 in mysql_parse (thd=0x7fd7d0000d50, rawbuf=0x7fd7d0012a78 "UPDATE t1 SET a= (SELECT 2 FROM t1 HAVING (a = 3))", length=50, parser_state=0x7fd7ec3a85c0, is_com_multi=false, is_next_command=false) at /10.3/sql/sql_parse.cc:7817
#22 0x0000563b2673c2ff in dispatch_command (command=COM_QUERY, thd=0x7fd7d0000d50, packet=0x7fd7d0008ed1 "UPDATE t1 SET a= (SELECT 2 FROM t1 HAVING (a = 3))", packet_length=50, is_com_multi=false, is_next_command=false) at /10.3/sql/sql_parse.cc:1855
#23 0x0000563b2673ac22 in do_command (thd=0x7fd7d0000d50) at /10.3/sql/sql_parse.cc:1401
#24 0x0000563b268b12b0 in do_handle_one_connection (connect=0x563b29c641b0) at /10.3/sql/sql_connect.cc:1403
#25 0x0000563b268b1012 in handle_one_connection (arg=0x563b29c641b0) at /10.3/sql/sql_connect.cc:1308
#26 0x0000563b27248745 in pfs_spawn_thread (arg=0x563b29c74fc0) at /10.3/storage/perfschema/pfs.cc:1869
#27 0x00007fd7f22c0fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#28 0x00007fd7f1c444cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Comment by Alice Sherepa [ 2021-08-27 ]

Test from MDEV-26415:

CREATE TABLE t1 AS SELECT NULL AS v1;
UPDATE t1 SET v1 = (SELECT v1 + 16 FROM t1 HAVING v1 + 57);

it fails the same way on 10.2-10.5, on 10.6 Assertion `*ref && (*ref)->fixed()' failed.

10.6 cc4e20e56f1e558a23

 
mariadbd: /10.6/src/sql/item.cc:7916: virtual bool Item_ref::fix_fields(THD*, Item**): Assertion `*ref && (*ref)->fixed()' failed.
210827 13:26:56 [ERROR] mysqld got signal 6 ;
 
:0(__GI___assert_fail)[0x7fd4c1f37f36]
sql/item.cc:7917(Item_ref::fix_fields(THD*, Item**))[0x55c48948c333]
sql/item.h:1144(Item::fix_fields_if_needed(THD*, Item**))[0x55c4888ea0fb]
sql/item_func.cc:347(Item_func::fix_fields(THD*, Item**))[0x55c48954955c]
sql/item.h:1144(Item::fix_fields_if_needed(THD*, Item**))[0x55c4888ea0fb]
sql/item.h:1148(Item::fix_fields_if_needed_for_scalar(THD*, Item**))[0x55c4888ea135]
sql/item.h:1153(Item::fix_fields_if_needed_for_bool(THD*, Item**))[0x55c488a20e41]
sql/sql_select.cc:1461(JOIN::prepare(TABLE_LIST*, Item*, unsigned int, st_order*, bool, st_order*, Item*, st_order*, st_select_lex*, st_select_lex_unit*))[0x55c488c4ef32]
sql/item_subselect.cc:3901(subselect_single_select_engine::prepare(THD*))[0x55c489648e6c]
sql/item_subselect.cc:295(Item_subselect::fix_fields(THD*, Item**))[0x55c489622e40]
sql/item.h:1144(Item::fix_fields_if_needed(THD*, Item**))[0x55c4888ea0fb]
sql/item.h:1148(Item::fix_fields_if_needed_for_scalar(THD*, Item**))[0x55c4888ea135]
sql/sql_base.cc:7694(setup_fields(THD*, Bounds_checked_array<Item*>, List<Item>&, enum_column_usage, List<Item>*, List<Item>*, bool))[0x55c488a1236f]
sql/sql_update.cc:2077(multi_update::prepare(List<Item>&, st_select_lex_unit*))[0x55c488ec8e88]
sql/sql_select.cc:1684(JOIN::prepare(TABLE_LIST*, Item*, unsigned int, st_order*, bool, st_order*, Item*, st_order*, st_select_lex*, st_select_lex_unit*))[0x55c488c51801]
sql/sql_select.cc:4969(mysql_select(THD*, TABLE_LIST*, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*))[0x55c488c745f3]
sql/sql_update.cc:1962(mysql_multi_update(THD*, TABLE_LIST*, List<Item>*, List<Item>*, Item*, unsigned long long, enum_duplicates, bool, st_select_lex_unit*, st_select_lex*, multi_update**))[0x55c488ec7a07]
sql/sql_parse.cc:4489(mysql_execute_command(THD*, bool))[0x55c488b9c2ce]
sql/sql_parse.cc:8030(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x55c488bb541a]
sql/sql_parse.cc:1898(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x55c488b8b4c8]
sql/sql_parse.cc:1404(do_command(THD*, bool))[0x55c488b881ec]
sql/sql_connect.cc:1418(do_handle_one_connection(CONNECT*, bool))[0x55c488fee1fb]
sql/sql_connect.cc:1314(handle_one_connection)[0x55c488feda87]
perfschema/pfs.cc:2203(pfs_spawn_thread)[0x55c489d0c697]
nptl/pthread_create.c:478(start_thread)[0x7fd4c244e609]
x86_64/clone.S:97(__GI___clone)[0x7fd4c2023293]
 
Query (0x62b0000c42a8): UPDATE t1 SET v1 = ( SELECT v1 + 16 FROM t1 HAVING v1 + 57 )

Comment by Oleksandr Byelkin [ 2021-09-20 ]

ref[0] points on the memory allocated in SELECT_LEX::vers_setup_conds but looks like freed

Comment by Aleksey Midenkov [ 2021-10-01 ]

Please review bb-10.3-midenok

Comment by Oleksandr Byelkin [ 2021-10-01 ]

commit 39349d65a3d6e6a0c4b4da01ff13edc4bfed8824 (origin/bb-10.3-midenok)
Author: Aleksey Midenkov <midenok@gmail.com>
Date:   Fri Oct 1 12:55:24 2021 +0300
 
    MDEV-22464 Server crash on UPDATE with nested subquery
    
    Uninitialized ref_pointer_array[] because setup_fields() got empty
    fields list.  mysql_multi_update() for some reason does that by
    substituting the fields list with empty total_list for the
    mysql_select() call (looks like wrong merge since total_list is not
    used anywhere else and is always empty). The fix would be to return
    back the original fields list. But this fails update_use_source.test
    case:
    
      --error ER_BAD_FIELD_ERROR
      update v1 set t1c1=2 order by 1;
    
    Actually not failing the above seems to be ok.
    
    The other fix would be to keep resolve_in_select_list false (and that
    keeps outer context from being resolved in
    Item_ref::fix_fields()). This fix is more consistent with how SELECT
    behaves:
    
      --error ER_SUBQUERY_NO_1_ROW
      select a from t1 where a= (select 2 from t1 having (a = 3));
    
    So this patch implements this fix.

Comment by Oleksandr Byelkin [ 2021-10-01 ]

OK to push

Generated at Thu Feb 08 09:14:55 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.