[MDEV-26456] SIGSEGV in flush_tables_with_read_lock on FLUSH TABLE Created: 2021-08-20  Updated: 2022-07-21  Resolved: 2022-07-21

Status: Closed
Project: MariaDB Server
Component/s: Locking, Stored routines, Views
Affects Version/s: 10.6, 10.7, 10.8, 10.9, 10.10
Fix Version/s: 10.6.9, 10.7.5, 10.8.4, 10.9.2

Type: Bug Priority: Critical
Reporter: Roel Van de Paar Assignee: Oleksandr Byelkin
Resolution: Fixed Votes: 0
Labels: not-10.2, not-10.3, not-10.4, not-10.5, regression

Issue Links:
Relates
relates to MDEV-25906 SIGSEGV in flush_tables_with_read_loc... Closed

 Description   

The testcases in bug MDEV-25906 now pass after the patch. However,

SET GLOBAL log_bin_trust_function_creators=ON;
CREATE FUNCTION f() RETURNS INT RETURN (SELECT 1 FROM t);
CREATE VIEW v AS SELECT f();
FLUSH TABLE v WITH READ LOCK;

Leads to:

10.7.0 52505bf20de0ce77a5c0b0a74af021051987bb0d (Debug)

Core was generated by `/test/MD160821-mariadb-10.7.0-linux-x86_64-dbg/bin/mysqld --no-defaults --core-'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055b31847b58d in flush_tables_with_read_lock (thd=thd@entry=
    0x150a94000db8, all_tables=<optimized out>)
    at /test/10.7_dbg/sql/sql_reload.cc:610
[Current thread is 1 (Thread 0x150ad8504700 (LWP 3707074))]
(gdb) bt
#0  0x000055b31847b58d in flush_tables_with_read_lock (thd=thd@entry=0x150a94000db8, all_tables=<optimized out>) at /test/10.7_dbg/sql/sql_reload.cc:610
#1  0x000055b3182d5606 in mysql_execute_command (thd=thd@entry=0x150a94000db8, is_called_from_prepared_stmt=is_called_from_prepared_stmt@entry=false) at /test/10.7_dbg/sql/sql_parse.cc:5406
#2  0x000055b3182bdac3 in mysql_parse (thd=thd@entry=0x150a94000db8, rawbuf=<optimized out>, length=<optimized out>, parser_state=parser_state@entry=0x150ad8503400) at /test/10.7_dbg/sql/sql_parse.cc:8030
#3  0x000055b3182cc6c8 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x150a94000db8, packet=packet@entry=0x150a9400b739 "FLUSH TABLE v WITH READ LOCK", packet_length=packet_length@entry=28, blocking=blocking@entry=true) at /test/10.7_dbg/sql/sql_class.h:1357
#4  0x000055b3182cfae9 in do_command (thd=0x150a94000db8, blocking=blocking@entry=true) at /test/10.7_dbg/sql/sql_parse.cc:1404
#5  0x000055b318445dd6 in do_handle_one_connection (connect=<optimized out>, connect@entry=0x55b31b9243f8, put_in_cache=put_in_cache@entry=true) at /test/10.7_dbg/sql/sql_connect.cc:1418
#6  0x000055b3184463db in handle_one_connection (arg=arg@entry=0x55b31b9243f8) at /test/10.7_dbg/sql/sql_connect.cc:1312
#7  0x000055b3188aece4 in pfs_spawn_thread (arg=0x55b31b84d048) at /test/10.7_dbg/storage/perfschema/pfs.cc:2201
#8  0x0000150adc5d1609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#9  0x0000150adc1bf293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

10.7.0 52505bf20de0ce77a5c0b0a74af021051987bb0d (Optimized)

Core was generated by `/test/MD160821-mariadb-10.7.0-linux-x86_64-opt/bin/mysqld --no-defaults --core-'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000556609ebbe9b in flush_tables_with_read_lock (thd=thd@entry=
    0x149c84000c58, all_tables=<optimized out>)
    at /test/10.7_opt/sql/sql_reload.cc:610
[Current thread is 1 (Thread 0x149cd0483700 (LWP 3745301))]
(gdb) bt
#0  0x0000556609ebbe9b in flush_tables_with_read_lock (thd=thd@entry=0x149c84000c58, all_tables=<optimized out>) at /test/10.7_opt/sql/sql_reload.cc:610
#1  0x0000556609d87418 in mysql_execute_command (thd=0x149c84000c58, is_called_from_prepared_stmt=<optimized out>) at /test/10.7_opt/sql/sql_parse.cc:5406
#2  0x0000556609d74336 in mysql_parse (thd=0x149c84000c58, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at /test/10.7_opt/sql/sql_parse.cc:8030
#3  0x0000556609d80225 in dispatch_command (command=COM_QUERY, thd=0x149c84000c58, packet=<optimized out>, packet_length=<optimized out>, blocking=<optimized out>) at /test/10.7_opt/sql/sql_class.h:1357
#4  0x0000556609d82147 in do_command (thd=0x149c84000c58, blocking=blocking@entry=true) at /test/10.7_opt/sql/sql_parse.cc:1404
#5  0x0000556609e9d967 in do_handle_one_connection (connect=<optimized out>, put_in_cache=true) at /test/10.7_opt/sql/sql_connect.cc:1418
#6  0x0000556609e9dcad in handle_one_connection (arg=arg@entry=0x55660d3d6dd8) at /test/10.7_opt/sql/sql_connect.cc:1312
#7  0x000055660a1f0648 in pfs_spawn_thread (arg=0x55660d002c88) at /test/10.7_opt/storage/perfschema/pfs.cc:2201
#8  0x0000149cd1dbc609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#9  0x0000149cd19aa293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bug confirmed present in:
MariaDB: 10.6.5 (dbg), 10.6.5 (opt), 10.7.0 (dbg), 10.7.0 (opt)

Bug (or feature/syntax) confirmed not present in:
MariaDB: 10.2.41 (dbg), 10.2.41 (opt), 10.3.32 (dbg), 10.3.32 (opt), 10.4.22 (dbg), 10.4.22 (opt), 10.5.13 (dbg), 10.5.13 (opt)
MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.51 (dbg), 5.6.51 (opt), 5.7.35 (dbg), 5.7.35 (opt), 8.0.26 (dbg), 8.0.26 (opt)



 Comments   
Comment by Oleksandr Byelkin [ 2021-09-02 ]

The problem is that flush_tables_with_read_lock somehow suppress open table error. Then it trys to use unopenned table which lead to the crash.

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

This testcase produces a new stack on optimized builds.

# mysqld options required for replay:  --log_bin_trust_function_creators=1
CREATE FUNCTION f() RETURNS INT RETURN (SELECT 1 FROM t);
CREATE VIEW v AS SELECT 0 AS a,f() AS DAYS;
FLUSH TABLES v FOR EXPORT;

Leads to:

10.10.0 081a284712bb661349e2e3802077b12211cede3e (Optimized)

Core was generated by `/test/MD310522-mariadb-10.10.0-linux-x86_64-opt/bin/mysqld --no-defaults --core'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000563f51a6db10 in flush_tables_with_read_lock (thd=thd@entry=
    0x1553b0000c58, all_tables=<optimized out>)
    at /test/10.10_opt/sql/sql_reload.cc:603
[Current thread is 1 (Thread 0x15541852b700 (LWP 656206))]
(gdb) bt
#0  0x0000563f51a6db10 in flush_tables_with_read_lock (thd=thd@entry=0x1553b0000c58, all_tables=<optimized out>) at /test/10.10_opt/sql/sql_reload.cc:603
#1  0x0000563f5193f8b1 in mysql_execute_command (thd=0x1553b0000c58, is_called_from_prepared_stmt=<optimized out>) at /test/10.10_opt/sql/sql_parse.cc:5411
#2  0x0000563f5192cbb5 in mysql_parse (rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>, thd=0x1553b0000c58) at /test/10.10_opt/sql/sql_parse.cc:8036
#3  mysql_parse (thd=0x1553b0000c58, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at /test/10.10_opt/sql/sql_parse.cc:7958
#4  0x0000563f519386ca in dispatch_command (command=COM_QUERY, thd=0x1553b0000c58, packet=<optimized out>, packet_length=<optimized out>, blocking=<optimized out>) at /test/10.10_opt/sql/sql_class.h:1364
#5  0x0000563f5193a5f2 in do_command (thd=0x1553b0000c58, blocking=blocking@entry=true) at /test/10.10_opt/sql/sql_parse.cc:1407
#6  0x0000563f51a508af in do_handle_one_connection (connect=<optimized out>, connect@entry=0x563f5379a5e8, put_in_cache=put_in_cache@entry=true) at /test/10.10_opt/sql/sql_connect.cc:1418
#7  0x0000563f51a50b8d in handle_one_connection (arg=0x563f5379a5e8) at /test/10.10_opt/sql/sql_connect.cc:1312
#8  0x0000155447010609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#9  0x0000155446bfc133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bug confirmed present in:
MariaDB: 10.6.9 (dbg), 10.6.9 (opt), 10.7.5 (dbg), 10.7.5 (opt), 10.8.4 (dbg), 10.8.4 (opt), 10.9.2 (dbg), 10.9.2 (opt), 10.10.0 (dbg), 10.10.0 (opt)

Bug (or feature/syntax) confirmed not present in:
MariaDB: 10.3.36 (dbg), 10.3.36 (opt), 10.4.26 (dbg), 10.4.26 (opt), 10.5.17 (dbg), 10.5.17 (opt)
MySQL: 5.5.62 (dbg), 5.5.62 (opt), 5.6.51 (dbg), 5.6.51 (opt), 5.7.38 (dbg), 5.7.38 (opt), 8.0.29 (dbg), 8.0.29 (opt)

Comment by Oleksandr Byelkin [ 2022-07-20 ]

The problem is that we mask "no such table" errors during opening tables due to placeholders, but in this case error happens in due to absence of table in the procedure.

Comment by Oleksandr Byelkin [ 2022-07-20 ]

Roel
SET GLOBAL log_bin_trust_function_creators=ON;
is not needed for bug repeating

Comment by Oleksandr Byelkin [ 2022-07-20 ]

bug is not repeatable in early versions because we can not lock views earlier.

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