[MDEV-25035] Server crash in JOIN::cleanup upon INSERT ..RETURNING with thousands frames in stack and no crash report in the error log Created: 2021-03-02  Updated: 2021-07-03

Status: Open
Project: MariaDB Server
Component/s: Data Manipulation - Insert
Affects Version/s: 10.5, 10.6
Fix Version/s: 10.5, 10.6

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Rucha Deodhar
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu Focal 5.8.0-43-generic #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux



 Description   

Note: The test case uses in_predicate_conversion_threshold=2 for brevity, but it's not limited to it. The issue is scalable, if the IN list is longer, the variable value can be bigger.

SET in_predicate_conversion_threshold= 2;
 
CREATE TABLE t (a INT);
INSERT INTO t VALUES (1),(2);
INSERT INTO t SELECT * FROM t WHERE a IN (3,4) RETURNING a;
 
# Cleanup
DROP TABLE t;

10.5 8d714db6

Thread 1 (Thread 0x7f77692ea700 (LWP 2495344)):
#0  0x0000564196c3d037 in _db_return_ (_stack_frame_=<error reading variable: Cannot access memory at address 0x7f77692a0ff8>) at /data/src/10.5/dbug/dbug.c:1198
#1  0x0000564195fb7192 in JOIN::cleanup (this=0x7f775801acd0, full=true) at /data/src/10.5/sql/sql_select.cc:13890
#2  0x000056419606c766 in st_select_lex::cleanup_all_joins (this=0x7f7758018868, full=true) at /data/src/10.5/sql/sql_union.cc:2788
#3  0x000056419606c7cc in st_select_lex::cleanup_all_joins (this=0x7f7758005760, full=true) at /data/src/10.5/sql/sql_union.cc:2795
<...>
<...>
#3048 0x000056419606c7cc in st_select_lex::cleanup_all_joins (this=0x7f7758018868, full=true) at /data/src/10.5/sql/sql_union.cc:2795
#3049 0x000056419606c7cc in st_select_lex::cleanup_all_joins (this=0x7f7758005760, full=true) at /data/src/10.5/sql/sql_union.cc:2795
#3050 0x0000564195fb6b5f in JOIN::join_free (this=0x7f7758017ee8) at /data/src/10.5/sql/sql_select.cc:13848
#3051 0x0000564195fc8da5 in do_select (join=0x7f7758017ee8, procedure=0x0) at /data/src/10.5/sql/sql_select.cc:20268
#3052 0x0000564195f9c4a0 in JOIN::exec_inner (this=0x7f7758017ee8) at /data/src/10.5/sql/sql_select.cc:4467
#3053 0x0000564195f9b5c1 in JOIN::exec (this=0x7f7758017ee8) at /data/src/10.5/sql/sql_select.cc:4247
#3054 0x0000564195f9cdf5 in mysql_select (thd=0x7f7758000db8, tables=0x7f77580160b8, fields=..., conds=0x7f7758016a70, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2202244745984, result=0x7f7758017e30, unit=0x7f7758004f60, select_lex=0x7f7758015ac8) at /data/src/10.5/sql/sql_select.cc:4720
#3055 0x0000564195f8c873 in handle_select (thd=0x7f7758000db8, lex=0x7f7758004e98, result=0x7f7758017e30, setup_tables_done_option=1073741824) at /data/src/10.5/sql/sql_select.cc:417
#3056 0x0000564195f48dfc in mysql_execute_command (thd=0x7f7758000db8) at /data/src/10.5/sql/sql_parse.cc:4743
#3057 0x0000564195f540de in mysql_parse (thd=0x7f7758000db8, rawbuf=0x7f77580152d0 "INSERT INTO t SELECT * FROM t WHERE a IN (3,4) RETURNING a", length=58, parser_state=0x7f77692e9510, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:8063
#3058 0x0000564195f40043 in dispatch_command (command=COM_QUERY, thd=0x7f7758000db8, packet=0x7f775800b589 "", packet_length=58, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1889
#3059 0x0000564195f3e837 in do_command (thd=0x7f7758000db8) at /data/src/10.5/sql/sql_parse.cc:1370
#3060 0x00005641960eca4d in do_handle_one_connection (connect=0x56419a14fbc8, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1410
#3061 0x00005641960ec7b0 in handle_one_connection (arg=0x56419a056c08) at /data/src/10.5/sql/sql_connect.cc:1312
#3062 0x000056419664d4e5 in pfs_spawn_thread (arg=0x56419a14f7f8) at /data/src/10.5/storage/perfschema/pfs.cc:2201
#3063 0x00007f776ee45609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#3064 0x00007f776ea19293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Attention: A coredump is created if configured so, but nothing is written into the error log at all, no sign of crash.

Reproducible on 10.5-10.6, debug, ASAN and release builds, all with the same effect.


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