[MDEV-17055] Server crashes in find_order_in_list upon 2nd (3rd) execution of SP with UPDATE Created: 2018-08-23  Updated: 2019-03-01  Resolved: 2019-03-01

Status: Closed
Project: MariaDB Server
Component/s: Data Manipulation - Update, Stored routines
Affects Version/s: 5.5, 10.0, 10.1, 10.2, 10.3, 10.4
Fix Version/s: 10.2.23, 5.5.64, 10.1.39, 10.3.14, 10.4.4

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Oleksandr Byelkin
Resolution: Fixed Votes: 0
Labels: affects-tests

Issue Links:
Blocks
blocks MDEV-17344 [Draft] Server crashes in Prepared_st... Open

 Description    

CREATE TABLE t1 (a INT);
 
CREATE VIEW v1 AS SELECT * FROM t1;
 
CREATE TABLE t2 (c INT);
 
 
 
CREATE PROCEDURE sp() UPDATE v1 SET a = 1 ORDER BY a, b LIMIT 1;
 
LOCK TABLE t2 READ;
 
--error ER_TABLE_NOT_LOCKED
 
CALL sp;
 
UNLOCK TABLES;
 
--error ER_BAD_FIELD_ERROR
 
CALL sp;
 
CALL sp;
 
 
 
# Cleanup
 
DROP PROCEDURE sp;
 
DROP VIEW v1;
 
DROP TABLE t1, t2;

10.0 bcc677bb7

 
#3  <signal handler called>
 
#4  0x00000000006b6642 in find_order_in_list (thd=0x7f1af96a2070, ref_pointer_array=0x7f1af7f5dba8, tables=0x7f1af7f5c088, order=0x7f1af7f5c910, fields=..., all_fields=..., is_group_field=false, add_to_all_fields=true) at /data/src/10.0/sql/sql_select.cc:21526
 
#5  0x00000000006b6bd9 in setup_order (thd=0x7f1af96a2070, ref_pointer_array=0x7f1af7f5dba8, tables=0x7f1af7f5c088, fields=..., all_fields=..., order=0x7f1af7f5c910) at /data/src/10.0/sql/sql_select.cc:21670
 
#6  0x000000000071a413 in mysql_prepare_update (thd=0x7f1af96a2070, table_list=0x7f1af7f5c088, conds=0x7f1b017e68c8, order_num=2, order=0x7f1af7f5c910) at /data/src/10.0/sql/sql_update.cc:1099
 
#7  0x0000000000718236 in mysql_update (thd=0x7f1af96a2070, table_list=0x7f1af7f5c088, fields=..., values=..., conds=0x0, order_num=2, order=0x7f1af7f5c910, limit=1, handle_duplicates=DUP_ERROR, ignore=false, found_return=0x7f1b017e7410, updated_return=0x7f1b017e7408) at /data/src/10.0/sql/sql_update.cc:329
 
#8  0x000000000064f164 in mysql_execute_command (thd=0x7f1af96a2070) at /data/src/10.0/sql/sql_parse.cc:3315
 
#9  0x000000000097f590 in sp_instr_stmt::exec_core (this=0x7f1af7f5cb58, thd=0x7f1af96a2070, nextp=0x7f1b017e7a68) at /data/src/10.0/sql/sp_head.cc:3210
 
#10 0x000000000097ec9f in sp_lex_keeper::reset_lex_and_exec_core (this=0x7f1af7f5cb98, thd=0x7f1af96a2070, nextp=0x7f1b017e7a68, open_tables=false, instr=0x7f1af7f5cb58) at /data/src/10.0/sql/sp_head.cc:2977
 
#11 0x000000000097f25a in sp_instr_stmt::execute (this=0x7f1af7f5cb58, thd=0x7f1af96a2070, nextp=0x7f1b017e7a68) at /data/src/10.0/sql/sp_head.cc:3126
 
#12 0x000000000097b02b in sp_head::execute (this=0x7f1af7fb3088, thd=0x7f1af96a2070, merge_da_on_success=true) at /data/src/10.0/sql/sp_head.cc:1369
 
#13 0x000000000097ccdf in sp_head::execute_procedure (this=0x7f1af7fb3088, thd=0x7f1af96a2070, args=0x7f1af96a66c8) at /data/src/10.0/sql/sp_head.cc:2157
 
#14 0x00000000006533e7 in mysql_execute_command (thd=0x7f1af96a2070) at /data/src/10.0/sql/sql_parse.cc:4727
 
#15 0x0000000000657d64 in mysql_parse (thd=0x7f1af96a2070, rawbuf=0x7f1af7da4088 "CALL sp", length=7, parser_state=0x7f1b017e8640) at /data/src/10.0/sql/sql_parse.cc:6637
 
#16 0x000000000064a684 in dispatch_command (command=COM_QUERY, thd=0x7f1af96a2070, packet=0x7f1afabe5071 "CALL sp", packet_length=7) at /data/src/10.0/sql/sql_parse.cc:1300
 
#17 0x0000000000649984 in do_command (thd=0x7f1af96a2070) at /data/src/10.0/sql/sql_parse.cc:1003
 
#18 0x000000000076acdc in do_handle_one_connection (thd_arg=0x7f1af96a2070) at /data/src/10.0/sql/sql_connect.cc:1377
 
#19 0x000000000076aa4e in handle_one_connection (arg=0x7f1af96a2070) at /data/src/10.0/sql/sql_connect.cc:1292
 
#20 0x0000000000accef0 in pfs_spawn_thread (arg=0x7f1af95a2370) at /data/src/10.0/storage/perfschema/pfs.cc:1861
 
#21 0x00007f1b0141c494 in start_thread (arg=0x7f1b017e9700) at pthread_create.c:333
 
#22 0x00007f1aff7d593f in clone () from /lib/x86_64-linux-gnu/libc.so.6

On 5.5 the stack trace is slightly different:

5.5 064ba8cc9

 
#3  <signal handler called>
 
#4  0x00000000006b4b54 in mysql_update (thd=0x7f0572664060, table_list=0x7f0571577078, fields=..., values=..., conds=0x0, order_num=2, order=0x7f0571577648, limit=1, handle_duplicates=DUP_ERROR, ignore=false, found_return=0x7f05782dd698, updated_return=0x7f05782dd690) at /data/src/5.5/sql/sql_update.cc:313
 
#5  0x0000000000602334 in mysql_execute_command (thd=0x7f0572664060) at /data/src/5.5/sql/sql_parse.cc:2839
 
#6  0x00000000008e2404 in sp_instr_stmt::exec_core (this=0x7f0571577880, thd=0x7f0572664060, nextp=0x7f05782ddc28) at /data/src/5.5/sql/sp_head.cc:3220
 
#7  0x00000000008e1bab in sp_lex_keeper::reset_lex_and_exec_core (this=0x7f05715778c0, thd=0x7f0572664060, nextp=0x7f05782ddc28, open_tables=false, instr=0x7f0571577880) at /data/src/5.5/sql/sp_head.cc:2998
 
#8  0x00000000008e212c in sp_instr_stmt::execute (this=0x7f0571577880, thd=0x7f0572664060, nextp=0x7f05782ddc28) at /data/src/5.5/sql/sp_head.cc:3144
 
#9  0x00000000008ddf95 in sp_head::execute (this=0x7f0571580078, thd=0x7f0572664060, merge_da_on_success=true) at /data/src/5.5/sql/sp_head.cc:1431
 
#10 0x00000000008dfcfb in sp_head::execute_procedure (this=0x7f0571580078, thd=0x7f0572664060, args=0x7f0572668020) at /data/src/5.5/sql/sp_head.cc:2197
 
#11 0x0000000000605f33 in mysql_execute_command (thd=0x7f0572664060) at /data/src/5.5/sql/sql_parse.cc:4115
 
#12 0x000000000060a4a2 in mysql_parse (thd=0x7f0572664060, rawbuf=0x7f0571548078 "CALL sp", length=7, parser_state=0x7f05782de640) at /data/src/5.5/sql/sql_parse.cc:5923
 
#13 0x00000000005fe1b7 in dispatch_command (command=COM_QUERY, thd=0x7f0572664060, packet=0x7f057635b061 "CALL sp", packet_length=7) at /data/src/5.5/sql/sql_parse.cc:1066
 
#14 0x00000000005fd3a9 in do_command (thd=0x7f0572664060) at /data/src/5.5/sql/sql_parse.cc:793
 
#15 0x0000000000700941 in do_handle_one_connection (thd_arg=0x7f0572664060) at /data/src/5.5/sql/sql_connect.cc:1268
 
#16 0x00000000007006ce in handle_one_connection (arg=0x7f0572664060) at /data/src/5.5/sql/sql_connect.cc:1184
 
#17 0x0000000000a0fe2d in pfs_spawn_thread (arg=0x7f0573376fc0) at /data/src/5.5/storage/perfschema/pfs.cc:1015
 
#18 0x00007f0577f11494 in start_thread (arg=0x7f05782df700) at pthread_create.c:333
 
#19 0x00007f057692793f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Both debug and non-debug versions are affected.

 Comments   
Comment by Elena Stepanova [ 2018-09-28 ]

Here is another representation of apparently the same problem:

10.2 non-debug 61a6f4bd9

 
pure virtual method called
 
terminate called without an active exception
 
180928  2:25:08 [ERROR] mysqld got signal 6 ;
 
 
 
#4  0x00007fe3eec853fa in abort () from /lib/x86_64-linux-gnu/libc.so.6
 
#5  0x00007fe3ef59a0ad in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
 
#6  0x00007fe3ef598066 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
 
#7  0x00007fe3ef5980b1 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
 
#8  0x00007fe3ef598b8f in __cxa_pure_virtual () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
 
#9  0x000055879b71ff95 in find_order_in_list (thd=0x7fe3680009a8, ref_pointer_array=..., tables=0xffffffffffffffff, tables@entry=0x7fe36804ed08, order=0x7fe368043c68, fields=..., all_fields=..., is_group_field=false, add_to_all_fields=true, from_window_spec=false) at /data/src/10.2/sql/sql_select.cc:22347
 
#10 0x000055879b73958f in setup_order (thd=0x7fe3680009a8, ref_pointer_array=..., tables=0x7fe36804ed08, fields=..., all_fields=..., order=0x7fe368043c68, from_window_spec=false) at /data/src/10.2/sql/sql_select.cc:22510
 
#11 0x000055879b7927b7 in mysql_prepare_update (thd=0x7fe3680009a8, table_list=0x7fe36804ed08, conds=0x7fe3e45fde20, order_num=4294967295, order_num@entry=5, order=0x0, order@entry=0x7fe368043c68) at /data/src/10.2/sql/sql_update.cc:1105
 
#12 0x000055879b792b7c in mysql_update (thd=0x7fe3680009a8, table_list=0x7fe36804ed08, fields=..., values=..., conds=0x7fe3680439b0, order_num=5, order=0x7fe368043c68, limit=7, handle_duplicates=DUP_ERROR, ignore=true, found_return=0x7fe3e45fe2c0, updated_return=0x7fe3e45fe370) at /data/src/10.2/sql/sql_update.cc:331
 
#13 0x000055879b6f7096 in mysql_execute_command (thd=0x7fe3680009a8) at /data/src/10.2/sql/sql_parse.cc:4290
 
#14 0x000055879b99b2d4 in sp_instr_stmt::exec_core (this=0x7fe3680de420, thd=<optimized out>, nextp=0x7fe3e45ff8c4) at /data/src/10.2/sql/sp_head.cc:3246
 
#15 0x000055879b9a1df3 in sp_lex_keeper::reset_lex_and_exec_core (this=this@entry=0x7fe3680de460, thd=thd@entry=0x7fe3680009a8, nextp=nextp@entry=0x7fe3e45ff8c4, open_tables=open_tables@entry=false, instr=instr@entry=0x7fe3680de420) at /data/src/10.2/sql/sp_head.cc:3009
 
#16 0x000055879b9a242c in sp_instr_stmt::execute (this=0x7fe3680de420, thd=0x7fe3680009a8, nextp=0x7fe3e45ff8c4) at /data/src/10.2/sql/sp_head.cc:3162
 
#17 0x000055879b99dfeb in sp_head::execute (this=this@entry=0x7fe36804d520, thd=thd@entry=0x7fe3680009a8, merge_da_on_success=merge_da_on_success@entry=true) at /data/src/10.2/sql/sp_head.cc:1327
 
#18 0x000055879b99f793 in sp_head::execute_procedure (this=0x7fe36804d520, thd=thd@entry=0x7fe3680009a8, args=0x7fe368005100) at /data/src/10.2/sql/sp_head.cc:2116
 
#19 0x000055879b6ee1f4 in do_execute_sp (thd=0x7fe3680009a8, sp=<optimized out>) at /data/src/10.2/sql/sql_parse.cc:2912
 
#20 0x000055879b6f79d2 in mysql_execute_command (thd=0x7fe3680009a8) at /data/src/10.2/sql/sql_parse.cc:5835
 
#21 0x000055879b6fdeb9 in mysql_parse (thd=0x7fe3680009a8, rawbuf=<optimized out>, length=42, parser_state=0x7fe3e4601260, is_com_multi=<optimized out>, is_next_command=<optimized out>) at /data/src/10.2/sql/sql_parse.cc:8011
 
#22 0x000055879b70091d in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x7fe3680009a8, packet=packet@entry=0x7fe368006d29 "CALL sp_grammar2 /* QNO 59485 CON_ID 16 */ ", packet_length=packet_length@entry=43, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/src/10.2/sql/sql_parse.cc:1824
 
#23 0x000055879b701178 in do_command (thd=0x7fe3680009a8) at /data/src/10.2/sql/sql_parse.cc:1378
 
#24 0x000055879b7c99f4 in do_handle_one_connection (connect=connect@entry=0x55879ea80198) at /data/src/10.2/sql/sql_connect.cc:1335
 
#25 0x000055879b7c9b94 in handle_one_connection (arg=0x55879ea80198) at /data/src/10.2/sql/sql_connect.cc:1241
 
#26 0x00007fe3f0953494 in start_thread (arg=0x7fe3e4602700) at pthread_create.c:333
 
#27 0x00007fe3eed3993f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Comment by Oleksandr Byelkin [ 2019-02-27 ]

It should not be ORDER (order caused by absence of cleanup if there was no execution run till its end)

CREATE PROCEDURE sp() UPDATE v1 SET a = 1 WHERE a=1 and b=2; 
LOCK TABLE t2 READ;
 
--error ER_TABLE_NOT_LOCKED
 
CALL sp;
 
UNLOCK TABLES;
 
--error ER_BAD_FIELD_ERROR
 
CALL sp;
 
--error ER_BAD_FIELD_ERROR
 
CALL sp;
 
--error ER_BAD_FIELD_ERROR
 
CALL sp;
 
 
 
# Cleanup
 
DROP PROCEDURE sp;

Comment by Oleksandr Byelkin [ 2019-02-28 ]

revision-id: a352dc57c8582be60c5c0b89f19c6f0cde78bd50 (mariadb-5.5.63-7-ga352dc57c85)
parent(s): 0ad598a00b17008b0c0702db40948b14d7eee0d5
author: Oleksandr Byelkin
committer: Oleksandr Byelkin
timestamp: 2019-02-28 17:21:43 +0100
message:

MDEV-17055: Server crashes in find_order_in_list upon 2nd (3rd) execution of SP with UPDATE

1. Always drop merged_for_insert flag on cleanup (there could be errors which prevent TABLE to be assigned)
2. Make more precise cleanup of select parts which was touched

—

Comment by Alexander Barkov [ 2019-02-28 ]

The patch:
https://github.com/mariadb/server/commit/a352dc57c8582be60c5c0b89f19c6f0cde78bd50
is OK to push.

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