[MDEV-28354] SIGSEGV's in free_root and st_join_table::cleanup Created: 2022-04-20  Updated: 2022-05-19  Resolved: 2022-05-18

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.2, 10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9
Fix Version/s: 10.2.44, 10.3.35, 10.4.25, 10.5.16, 10.6.8, 10.7.4, 10.8.3

Type: Bug Priority: Critical
Reporter: Roel Van de Paar Assignee: Oleg Smirnov
Resolution: Cannot Reproduce Votes: 0
Labels: affects-tests, hang, memory_corruption

Issue Links:
Relates
relates to MDEV-24560 SIGSEGV in st_join_table::cleanup + s... Closed

 Description   

Split from MDEV-24560

SET big_tables=ON;
 
CREATE TABLE t (a VARCHAR(16383) CHARACTER SET UTF32,KEY k1 (a (768))) ENGINE=InnoDB;
 
SET SESSION sql_buffer_result=1;
 
DELETE FROM mysql.user WHERE USER=0;
 
EXPLAIN SELECT COUNT(DISTINCT a) FROM t;

Which produces the following uniqueID's:

SIGSEGV|_int_free|free_root|free_tmp_table|JOIN::cleanup
 
SIGSEGV|_int_free|root_free|free_root|free_tmp_table
 
SIGSEGV|st_join_table::cleanup|JOIN::cleanup|JOIN::destroy|st_select_lex::cleanup

With the first two of those being new ones.
Here are two example traces for those uniqueID's:

10.5.16 73fee39ea62037780c59161507e89dd76c10b7a3 (Optimized)

 
Core was generated by `/test/MD160322-mariadb-10.5.16-linux-x86_64-opt/bin/mysqld --no-defaults --core'.
 
Program terminated with signal SIGSEGV, Segmentation fault.
 
#0  _int_free (av=0x14aa57165b80 <main_arena>, p=0x14a9cc0b3650, 
    have_lock=<optimized out>) at malloc.c:4316
 
[Current thread is 1 (Thread 0x14aa543fa700 (LWP 2286515))]
 
(gdb) bt
 
#0  _int_free (av=0x14aa57165b80 <main_arena>, p=0x14a9cc0b3650, have_lock=<optimized out>) at malloc.c:4316
 
#1  0x000056297d628b45 in free_root (root=root@entry=0x14aa543f8d60, MyFlags=MyFlags@entry=0) at /test/10.5_opt/mysys/my_alloc.c:410
 
#2  0x000056297ce84b60 in free_tmp_table (thd=0x14a9cc000c58, entry=0x14a9cc0435e0) at /test/10.5_opt/sql/sql_select.cc:20211
 
#3  0x000056297ce9ea1f in JOIN::cleanup (this=this@entry=0x14a9cc012410, full=full@entry=true) at /test/10.5_opt/sql/sql_select.cc:14065
 
#4  0x000056297ce9ed3a in JOIN::destroy (this=0x14a9cc012410) at /test/10.5_opt/sql/sql_select.cc:4567
 
#5  0x000056297cef7abd in st_select_lex::cleanup (this=this@entry=0x14a9cc0104a8) at /test/10.5_opt/sql/sql_union.cc:2790
 
#6  0x000056297cef7cf0 in st_select_lex_unit::cleanup (this=0x14a9cc004c40) at /test/10.5_opt/sql/sql_union.cc:2596
 
#7  st_select_lex_unit::cleanup (this=this@entry=0x14a9cc004c40) at /test/10.5_opt/sql/sql_union.cc:2557
 
#8  0x000056297ce3e57c in mysql_execute_command (thd=0x14a9cc000c58) at /test/10.5_opt/sql/sql_parse.cc:6085
 
#9  0x000056297ce2ddb3 in mysql_parse (thd=0x14a9cc000c58, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>, is_com_multi=<optimized out>, is_next_command=<optimized out>) at /test/10.5_opt/sql/sql_parse.cc:8100
 
#10 0x000056297ce3abcd in dispatch_command (command=COM_QUERY, thd=0x14a9cc000c58, packet=<optimized out>, packet_length=<optimized out>, is_com_multi=<optimized out>, is_next_command=<optimized out>) at /test/10.5_opt/sql/sql_class.h:1290
 
#11 0x000056297ce3d3a2 in do_command (thd=0x14a9cc000c58) at /test/10.5_opt/sql/sql_parse.cc:1370
 
#12 0x000056297cf44f31 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x562980469788, put_in_cache=put_in_cache@entry=true) at /test/10.5_opt/sql/sql_connect.cc:1418
 
#13 0x000056297cf453ad in handle_one_connection (arg=arg@entry=0x562980469788) at /test/10.5_opt/sql/sql_connect.cc:1312
 
#14 0x000056297d2da4f2 in pfs_spawn_thread (arg=0x5629803ea438) at /test/10.5_opt/storage/perfschema/pfs.cc:2201
 
#15 0x000014aa574ac609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 
#16 0x000014aa57098163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

10.9.0 5be92887c2caacb45af87b1131db952ce627e83a (Optimized)

 
Core was generated by `/test/MD160322-mariadb-10.9.0-linux-x86_64-opt/bin/mysqld --no-defaults --core-'.
 
Program terminated with signal SIGSEGV, Segmentation fault.
 
#0  _int_free (av=0x150515628b80 <main_arena>, p=0x1504600b1f80, 
    have_lock=<optimized out>) at malloc.c:4316
 
[Current thread is 1 (Thread 0x1504f41a6700 (LWP 2454660))]
 
(gdb) bt
 
#0  _int_free (av=0x150515628b80 <main_arena>, p=0x1504600b1f80, have_lock=<optimized out>) at malloc.c:4316
 
#1  0x000055f19aad94f5 in root_free (root=0x1504f41a4de0, size=<optimized out>, ptr=<optimized out>) at /test/10.9_opt/mysys/my_alloc.c:78
 
#2  free_root (root=root@entry=0x1504f41a4de0, MyFlags=MyFlags@entry=0) at /test/10.9_opt/mysys/my_alloc.c:495
 
#3  0x000055f19a39f589 in free_tmp_table (thd=0x150460000c58, entry=0x15046003f560) at /test/10.9_opt/sql/sql_select.cc:20406
 
#4  0x000055f19a3b8cdf in JOIN::cleanup (this=this@entry=0x150460012708, full=full@entry=true) at /test/10.9_opt/sql/sql_select.cc:14280
 
#5  0x000055f19a3b904a in JOIN::destroy (this=0x150460012708) at /test/10.9_opt/sql/sql_select.cc:4778
 
#6  0x000055f19a41401d in st_select_lex::cleanup (this=this@entry=0x150460010968) at /test/10.9_opt/sql/sql_union.cc:2788
 
#7  0x000055f19a414258 in st_select_lex_unit::cleanup (this=0x150460004ea8) at /test/10.9_opt/sql/sql_union.cc:2594
 
#8  st_select_lex_unit::cleanup (this=this@entry=0x150460004ea8) at /test/10.9_opt/sql/sql_union.cc:2555
 
#9  0x000055f19a34b564 in mysql_execute_command (thd=0x150460000c58, is_called_from_prepared_stmt=<optimized out>) at /test/10.9_opt/sql/sql_parse.cc:6017
 
#10 0x000055f19a33c1c6 in mysql_parse (thd=0x150460000c58, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at /test/10.9_opt/sql/sql_parse.cc:8027
 
#11 0x000055f19a348375 in dispatch_command (command=COM_QUERY, thd=0x150460000c58, packet=<optimized out>, packet_length=<optimized out>, blocking=<optimized out>) at /test/10.9_opt/sql/sql_class.h:1362
 
#12 0x000055f19a34a567 in do_command (thd=0x150460000c58, blocking=blocking@entry=true) at /test/10.9_opt/sql/sql_parse.cc:1402
 
#13 0x000055f19a469e97 in do_handle_one_connection (connect=<optimized out>, put_in_cache=true) at /test/10.9_opt/sql/sql_connect.cc:1418
 
#14 0x000055f19a46a1dd in handle_one_connection (arg=arg@entry=0x55f19c89fc38) at /test/10.9_opt/sql/sql_connect.cc:1312
 
#15 0x000055f19a7e38d1 in pfs_spawn_thread (arg=0x55f19c8579c8) at /test/10.9_opt/storage/perfschema/pfs.cc:2201
 
#16 0x000015051596f609 in start_thread (arg=<optimized out>) at pthread_create.c:477
 
#17 0x000015051555b163 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Additionally, 10.2.44 (opt) hangs when running the testcase, and any CLI connect will hang also. The issue is readily reproducible. GDB break-in coredump can be provided if needed, but I assume it's easy to reproduce on your site for the same (if the patch does not fix it)

 Comments   
Comment by Oleg Smirnov [ 2022-05-01 ]

1. I can't reproduce the crash on the trunk versions of 10.2 and 10.5 (though I could before). Please check if you can.

2. Doesn't it look incorrect that condition User=0 satisfy all records in mysql.user? So DELETE FROM mysql.user WHERE USER=0 deletes all rows. Field 'User' is of char(80) data type. Less harmful examples:

select * from mysql.user where User=0;
 
<...all records are displayed>
 
 
 
show warnings;
 
+---------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
 
| Level   | Code | Message                                                                                                                                                              |
 
+---------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
 
| Warning | 1292 | Truncated incorrect DOUBLE value: '                                                                                                                             ...' |
 
| Warning | 1292 | Truncated incorrect DOUBLE value: 'root                                                                                                                         ...' |
 
| Warning | 1292 | Truncated incorrect DOUBLE value: '                                                                                                                             ...' |
 
| Warning | 1292 | Truncated incorrect DOUBLE value: 'root                                                                                                                         ...' |
 
| Warning | 1292 | Truncated incorrect DOUBLE value: 'root                                                                                                                         ...' |
 
| Warning | 1292 | Truncated incorrect DOUBLE value: 'root                                                                                                                         ...' |
 
+---------+------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
 
6 rows in set (0.00 sec)
 
 
 
select * from mysql.user where User=0.0;
 
<...all records are displayed>
 
 
 
create table tab1 (`User` char(80) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT '');
 
 
 
insert into tab1 values ('admin'),('guest'),('user');
 
 
 
select * from tab1 where User=0;
 
+-------+
 
| User  |
 
+-------+
 
| admin |
 
| guest |
 
| user  |
 
+-------+
 
 
 
MariaDB [test]> select * from tab1 where User=0.0;
 
+-------+
 
| User  |
 
+-------+
 
| admin |
 
| guest |
 
| user  |
 
+-------+

I suspect a bug in the implicit data types conversion.

Comment by Roel Van de Paar [ 2022-05-03 ]

I rebuild 10.9 trunk and am no longer able to reproduce the crashes either.

Very interesting on the findings. bar Do you have some helpful input for us here? Thank you

Comment by Oleg Smirnov [ 2022-05-06 ]

Discussed the suspected type conversion issue with psergei, and it looks like there are no bugs here. When a character type field is compared against a numeric value then the character type is converted to double type. Non-numeric strings that cannot be converted (and apparently NULLs) are assigned 0 value. That's why 

select * from mysql.user where User=0

return all records from the User table.

Regarding the crash that cannot be reproduced: do you think we need to investigate this and find the commit that has fixed it? Or we can just close this ticket?

Comment by Roel Van de Paar [ 2022-05-06 ]

oleg.smirnov Thank you. On the investigation: up to you. Either works for me.

Comment by Oleg Smirnov [ 2022-05-18 ]

I don't the investigation is worth spending time so I suggest to close the issue.

Comment by Roel Van de Paar [ 2022-05-19 ]

Thank you!

Generated at Thu Feb 08 10:00:05 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.