[MDEV-26427] MariaDB Server SEGV on INSERT .. SELECT Created: 2021-08-19  Updated: 2024-01-09  Resolved: 2022-07-14

Status: Closed
Project: MariaDB Server
Component/s: Optimizer - Window functions
Affects Version/s: 10.7.0, 10.2, 10.3, 10.4, 10.5, 10.6, 10.7, 10.8
Fix Version/s: 10.3.36, 10.4.26, 10.5.17, 10.6.9, 10.7.5, 10.8.4, 10.9.2

Type: Bug Priority: Blocker
Reporter: Jingzhou Fu Assignee: Oleg Smirnov
Resolution: Fixed Votes: 0
Labels: fuzzer
Environment:

Linux version 5.13.0-1-MANJARO (builduser@LEGION) (gcc (GCC) 11.1.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP PREEMPT Mon Jun 7 06:16:10 UTC 2021 x86_64



 Description   

step to reproduce:

CREATE TABLE v0 ( v1 DECIMAL UNIQUE CHECK ( CASE 0 * 27302337.000000 WHEN 34 THEN + 'x' LIKE 'x' OR v1 NOT IN ( -1 / TRUE ^ 2 ) ELSE 7105743.000000 END ) ) ;
 INSERT INTO v0 VALUES ( 90 ) , ( -1 ) , ( 31152443.000000 ) , ( -32768 ) , ( NULL ) , ( NULL ) ;
 INSERT INTO v0 SELECT AVG ( 'x' ) OVER ( PARTITION BY ( ( NOT AVG ( 76698761.000000 ) ) ) IS NOT NULL ) ;
 INSERT IGNORE INTO v0 ( ) VALUES ( 0 ) , ( 'x' ) , ( 3751286.000000 ) , ( 'x' ) , ( ( v1 = 'x' AND 0 AND 0 ) ) ;
 INSERT INTO v0 VALUES ( 127 ) ;
 INSERT INTO v0 SELECT -2147483648 END FROM v0 AS TEXT JOIN v0 JOIN v0 TABLES ;
 ALTER TABLE v0 ADD ( v2 INT UNIQUE CHECK ( ( v1 = 'x' AND ( ( - ( + ( BINARY 49730460.000000 ) ) ) ) = 'x' BETWEEN 'x' AND 'x' ) ) ) ;
 UPDATE v0 SET v1 = -128 WHERE v1 IS NULL ORDER BY 78 IN ( 'x' , 'x' ) , v1 ;

report (compiled with ASAN):

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.7.0-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=1
max_threads=153
thread_count=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467956 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x62b0000bd218
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 = 0x7f4adf25c850 thread_stack 0x5fc00
sanitizer_common/sanitizer_common_interceptors.inc:4203(__interceptor_backtrace.part.0)[0x7f4afeb08c3e]
mysys/stacktrace.c:213(my_print_stacktrace)[0x55a35785f747]
sql/signal_handler.cc:222(handle_fatal_signal)[0x55a356827120]
sigaction.c:0(__restore_rt)[0x7f4afe4f2870]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x629000087238): INSERT INTO v0 SELECT AVG ( 'x' ) OVER ( PARTITION BY ( ( NOT AVG ( 76698761.000000 ) ) ) IS NOT NULL )
 
Connection ID (thread ID): 4
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 https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /home/fuboat/mariadb-tmp/3
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             61608                61608                processes 
Max open files            524288               524288               files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       61608                61608                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: core

gdb bt:

#0  0x00007f4afe4ef808 in pthread_kill () from /usr/lib/libpthread.so.0
#1  0x000055a35682706b in handle_fatal_signal (sig=<optimized out>) at /experiment/mariadb-server/sql/signal_handler.cc:344
#2  <signal handler called>
#3  0x0000000000000000 in ?? ()
#4  0x000055a3561b9ee7 in sub_select (join=0x629000089208, join_tab=0x629000089c88, end_of_records=false) at /experiment/mariadb-server/sql/sql_select.cc:21052
#5  0x000055a35625eb8d in do_select (procedure=0x0, join=0x629000089208) at /experiment/mariadb-server/sql/sql_select.cc:20602
#6  JOIN::exec_inner (this=0x629000089208) at /experiment/mariadb-server/sql/sql_select.cc:4735
#7  0x000055a356260593 in JOIN::exec (this=this@entry=0x629000089208) at /experiment/mariadb-server/sql/sql_select.cc:4513
#8  0x000055a356258b5b in mysql_select (thd=0x62b0000bd218, tables=<optimized out>, fields=..., conds=<optimized out>, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=<optimized out>, result=0x629000089140, unit=0x62b0000c13c0, select_lex=0x629000087ad0)
    at /experiment/mariadb-server/sql/sql_select.cc:4991
#9  0x000055a35625a655 in handle_select (thd=thd@entry=0x62b0000bd218, lex=lex@entry=0x62b0000c12f8, result=result@entry=0x629000089140, setup_tables_done_option=setup_tables_done_option@entry=1073741824) at /experiment/mariadb-server/sql/sql_select.cc:545
#10 0x000055a3560c99c1 in mysql_execute_command (thd=0x62b0000bd218, is_called_from_prepared_stmt=<optimized out>) at /experiment/mariadb-server/sql/sql_parse.cc:4711
#11 0x000055a3560cc5a1 in mysql_parse (thd=0x62b0000bd218, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at /experiment/mariadb-server/sql/sql_parse.cc:8030
#12 0x000055a3560d260c in dispatch_command (command=<optimized out>, thd=0x62b0000bd218, packet=<optimized out>, packet_length=<optimized out>, blocking=<optimized out>) at /experiment/mariadb-server/sql/sql_parse.cc:1896
#13 0x000055a3560d773d in do_command (thd=0x62b0000bd218, blocking=blocking@entry=true) at /experiment/mariadb-server/sql/sql_parse.cc:1404
#14 0x000055a356492e57 in do_handle_one_connection (connect=<optimized out>, put_in_cache=<optimized out>) at /experiment/mariadb-server/sql/sql_connect.cc:1418
#15 0x000055a35649333d in handle_one_connection (arg=arg@entry=0x6080000023b8) at /experiment/mariadb-server/sql/sql_connect.cc:1312
#16 0x000055a356f23c2c in pfs_spawn_thread (arg=0x617000005f18) at /experiment/mariadb-server/storage/perfschema/pfs.cc:2201
#17 0x00007f4afe4e8259 in start_thread () from /usr/lib/libpthread.so.0
#18 0x00007f4afe0935e3 in clone () from /usr/lib/libc.so.6



 Comments   
Comment by Alice Sherepa [ 2021-08-25 ]

Thank you!
I repeated on 10.2-10.6:

CREATE TABLE t1 (a int);
INSERT INTO t1 SELECT AVG ('x') OVER ();

10.2 1f1d5606e08c928e3da98b

#2  0x000055b7dd4e3831 in handle_fatal_signal (sig=11) at /10.2/src/sql/signal_handler.cc:355
#3  <signal handler called>
#4  0x0000000000000000 in ?? ()
#5  0x000055b7dd2cfe76 in sub_select (join=0x7f69ac013350, join_tab=0x7f69ac013b10, end_of_records=false) at /10.2/src/sql/sql_select.cc:18892
#6  0x000055b7dd2cf43a in do_select (join=0x7f69ac013350, procedure=0x0) at /10.2/src/sql/sql_select.cc:18439
#7  0x000055b7dd2a8f4b in JOIN::exec_inner (this=0x7f69ac013350) at /10.2/src/sql/sql_select.cc:3651
#8  0x000055b7dd2a83f2 in JOIN::exec (this=0x7f69ac013350) at /10.2/src/sql/sql_select.cc:3446
#9  0x000055b7dd2a95cc in mysql_select (thd=0x7f69ac000d90, tables=0x0, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=3489925888, result=0x7f69ac0132a8, unit=0x7f69ac004988, select_lex=0x7f69ac0050d8) at /10.2/src/sql/sql_select.cc:3849
#10 0x000055b7dd29d720 in handle_select (thd=0x7f69ac000d90, lex=0x7f69ac0048c8, result=0x7f69ac0132a8, setup_tables_done_option=1073741824) at /10.2/src/sql/sql_select.cc:361
#11 0x000055b7dd260d4c in mysql_execute_command (thd=0x7f69ac000d90) at /10.2/src/sql/sql_parse.cc:4333
#12 0x000055b7dd26bb42 in mysql_parse (thd=0x7f69ac000d90, rawbuf=0x7f69ac012708 "INSERT INTO t1 SELECT AVG ('x') OVER ()", length=39, parser_state=0x7f69fa1fc560, is_com_multi=false, is_next_command=false) at /10.2/src/sql/sql_parse.cc:7793
#13 0x000055b7dd259d9d in dispatch_command (command=COM_QUERY, thd=0x7f69ac000d90, packet=0x7f69ac008b61 "INSERT INTO t1 SELECT AVG ('x') OVER ()", packet_length=39, is_com_multi=false, is_next_command=false) at /10.2/src/sql/sql_parse.cc:1827
#14 0x000055b7dd258898 in do_command (thd=0x7f69ac000d90) at /10.2/src/sql/sql_parse.cc:1381
#15 0x000055b7dd3b4661 in do_handle_one_connection (connect=0x55b7e01b3a90) at /10.2/src/sql/sql_connect.cc:1336
#16 0x000055b7dd3b43c6 in handle_one_connection (arg=0x55b7e01b3a90) at /10.2/src/sql/sql_connect.cc:1241
#17 0x000055b7ddbddec4 in pfs_spawn_thread (arg=0x55b7e0196d50) at /10.2/src/storage/perfschema/pfs.cc:1869
#18 0x00007f6a003d7609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#19 0x00007f69fffb2293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Comment by Oleg Smirnov [ 2022-06-14 ]

Another observation of incorrect behavior - aggregate function returns non-NULL value but NULL is inserted instead.

MariaDB [test]> CREATE TABLE t1 (a int);
 
MariaDB [test]> select avg(9);
+--------+
| avg(9) |
+--------+
| 9.0000 |
+--------+
1 row in set (4.615 sec)
 
MariaDB [test]> insert into t1 select avg(9);
Query OK, 1 row affected (0.002 sec)
Records: 1  Duplicates: 0  Warnings: 0
 
MariaDB [test]> select * from t1;
+------+
| a    |
+------+
| NULL |
+------+
1 row in set (5.886 sec)

Same with other aggregate functions, for example:

 select sum(9); 

Comment by Oleg Smirnov [ 2022-07-12 ]

Pushed into bb-10.3-MDEV-26427

Comment by Oleksandr Byelkin [ 2022-07-12 ]

OK to push

Comment by Oleg Smirnov [ 2022-07-14 ]

Pushed to 10.3

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