[MDEV-15040] Crash in st_select_lex::cleanup() in stored procedure from the package Created: 2018-01-23  Updated: 2020-08-25  Resolved: 2018-06-28

Status: Closed
Project: MariaDB Server
Component/s: Stored routines
Affects Version/s: N/A
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Valerii Kravchuk Assignee: Alexander Barkov
Resolution: Not a Bug Votes: 0
Labels: None
Environment:

bb-10.2-compatibility build 18009

Issue Links:
Relates
relates to MDEV-15070 Crash when doing a CREATE VIEW inside... Closed
relates to MDEV-15080 ASAN heap-use-after-free in Query_tab... Closed

 Description   

We have the following crash (build 18009) boted in the error log:

Thread pointer: 0x7f8bf00009a8
 
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 = 0x7f8d46328d70 thread_stack 0x40000
 
(my_addr_resolve failure: fork)
 
/usr/sbin/mysqld(my_print_stacktrace+0x2e) [0x55fae7caeb5e]
 
/usr/sbin/mysqld(handle_fatal_signal+0x355) [0x55fae773ffc5]
 
/lib64/libpthread.so.0(+0xf5e0) [0x7fa262e4c5e0]
 
/usr/sbin/mysqld(st_select_lex::cleanup()+0x20) [0x55fae7613a70]
 
/usr/sbin/mysqld(st_select_lex_unit::cleanup()+0x40) [0x55fae7613bd0]
 
/usr/sbin/mysqld(mysql_execute_command(THD*)+0x742) [0x55fae757cae2]
 
/usr/sbin/mysqld(sp_instr_stmt::exec_core(THD*, unsigned int*)+0x36) [0x55fae74f5cf6]
 
/usr/sbin/mysqld(sp_lex_keeper::reset_lex_and_exec_core(THD*, unsigned int*, bool, sp_instr*)+0x99) [0x55fae74fd959]
 
/usr/sbin/mysqld(sp_instr_stmt::execute(THD*, unsigned int*)+0x205) [0x55fae74fdf55]
 
/usr/sbin/mysqld(sp_head::execute(THD*, bool)+0x816) [0x55fae74f99c6]
 
/usr/sbin/mysqld(sp_head::execute_procedure(THD*, List<Item>*)+0x72d) [0x55fae74faaed]
 
/usr/sbin/mysqld(+0x55d86b) [0x55fae757586b]
 
/usr/sbin/mysqld(+0x55f596) [0x55fae7577596]
 
/usr/sbin/mysqld(Sql_cmd_call::execute(THD*)+0x90) [0x55fae7577d90]
 
/usr/sbin/mysqld(mysql_execute_command(THD*)+0x13fe) [0x55fae757d79e]
 
/usr/sbin/mysqld(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool)+0x2fe) [0x55fae758554e]
 
/usr/sbin/mysqld(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool)+0x20d0) [0x55fae7588640]
 
/usr/sbin/mysqld(do_command(THD*)+0x149) [0x55fae7589249]
 
/usr/sbin/mysqld(do_handle_one_connection(CONNECT*)+0x1aa) [0x55fae764f89a]
 
/usr/sbin/mysqld(handle_one_connection+0x3d) [0x55fae764f9bd]
 
/lib64/libpthread.so.0(+0x7e25) [0x7fa262e44e25]
 
/lib64/libc.so.6(clone+0x6d) [0x7fa26149734d]
 
 
 
Trying to get some variables.
 
Some pointers may be invalid and cause the dump to abort.
 
Query (0x7f8bf0817508): SOME_PKG.SOME_SP( NAME_CONST('pP1',_utf8mb4'AU' COLLATE 'utf8mb4_bin'), NAME_CONST('pP2',TIMESTAMP'2017-11-30 00:00:00'))
 
Connection ID (thread ID): 4317
 
Status: NOT_KILLED



 Comments   
Comment by Elena Stepanova [ 2018-01-23 ]

the push history of bb-10.2-compatibility is difficult to follow, but as I understand, it's supposed to be either already fixed in some build after 18201, or be fixed by one of the upcoming pushes, or at least be more easily debuggable after the build 18234.

bar, could you please suggest the best course of action, which build the instance should be upgrade to?

Comment by Alexander Barkov [ 2018-01-24 ]

In this build:
http://hasky.askmonty.org/archive/bb-10.2-compatibility/build-18253/
the issue should be easier to debug.
There is also a chance that this issue was also fixed by MDEV-14603.

Comment by Elena Stepanova [ 2018-01-27 ]

I got the same stack trace during concurrent tests on bb-10.2-compatibility build 18296, it's one of variations reported in MDEV-15080:

#2  <signal handler called>
 
#3  st_select_lex::cleanup (this=0x7f2500000000) at /data/src/bb-10.2-compatibility/sql/sql_union.cc:1902
 
#4  0x000055e7465846a8 in st_select_lex_unit::cleanup (this=0x7f2500000000) at /data/src/bb-10.2-compatibility/sql/sql_union.cc:1741
 
#5  0x000055e7464ebad8 in mysql_execute_command (thd=0x7f25a00009a8) at /data/src/bb-10.2-compatibility/sql/sql_parse.cc:6279
 
#6  0x000055e74646cc04 in sp_instr_stmt::exec_core (this=0x7f25a0085668, thd=<optimized out>, nextp=0x7f2738201134) at /data/src/bb-10.2-compatibility/sql/sp_head.cc:3591
 
#7  0x000055e7464741a3 in sp_lex_keeper::reset_lex_and_exec_core (this=this@entry=0x7f25a00856b0, thd=thd@entry=0x7f25a00009a8, nextp=nextp@entry=0x7f2738201134, open_tables=open_tables@entry=false, instr=instr@entry=0x7f25a0085668) at /data/src/bb-10.2-compatibility/sql/sp_head.cc:3336
 
#8  0x000055e7464747ec in sp_instr_stmt::execute (this=0x7f25a0085668, thd=0x7f25a00009a8, nextp=0x7f2738201134) at /data/src/bb-10.2-compatibility/sql/sp_head.cc:3507
 
#9  0x000055e7464704cd in sp_head::execute (this=0x7f25a04b7e80, thd=0x7f25a00009a8, merge_da_on_success=<optimized out>) at /data/src/bb-10.2-compatibility/sql/sp_head.cc:1390
 
#10 0x000055e74647153e in sp_head::execute_procedure (this=0x7f25a04b7e80, thd=0x7f25a00009a8, args=0x58) at /data/src/bb-10.2-compatibility/sql/sp_head.cc:2313
 
#11 0x000055e7464e531d in do_execute_sp (thd=0x7f25a00009a8, sp=0x7f2500000000, sp@entry=0x7f25a00009a8) at /data/src/bb-10.2-compatibility/sql/sql_parse.cc:2929
 
#12 0x000055e7464e6976 in Sql_cmd_call::execute (this=this@entry=0x7f25a000fb98, thd=thd@entry=0x7f25a00009a8) at /data/src/bb-10.2-compatibility/sql/sql_parse.cc:3169
 
#13 0x000055e7464e71e7 in Sql_cmd_call::execute (this=0x7f25a000fb98, thd=0x7f25a00009a8) at /data/src/bb-10.2-compatibility/sql/sql_parse.cc:3123
 
#14 0x000055e7464ec722 in mysql_execute_command (thd=0x7f25a00009a8) at /data/src/bb-10.2-compatibility/sql/sql_parse.cc:6254
 
#15 0x000055e7464f304d in mysql_parse (thd=0x7f25a00009a8, rawbuf=<optimized out>, length=63, parser_state=0x7f2738203260, is_com_multi=<optimized out>, is_next_command=<optimized out>) at /data/src/bb-10.2-compatibility/sql/sql_parse.cc:7974
 
#16 0x000055e7464f6555 in dispatch_command (command=command@entry=COM_QUERY, thd=thd@entry=0x7f25a00009a8, packet=packet@entry=0x7f25a0006fa9 " CALL pkg.pr4(NOW())  /* QNO 608 CON_ID 16 */ ", packet_length=packet_length@entry=65, is_com_multi=is_com_multi@entry=false, is_next_command=is_next_command@entry=false) at /data/src/bb-10.2-compatibility/sql/sql_parse.cc:1835
 
#17 0x000055e7464f6e23 in do_command (thd=0x7f25a00009a8) at /data/src/bb-10.2-compatibility/sql/sql_parse.cc:1383
 
#18 0x000055e7465bf594 in do_handle_one_connection (connect=connect@entry=0x55e750acda18) at /data/src/bb-10.2-compatibility/sql/sql_connect.cc:1335
 
#19 0x000055e7465bf734 in handle_one_connection (arg=0x55e750acda18) at /data/src/bb-10.2-compatibility/sql/sql_connect.cc:1241
 
#20 0x00007f274e853494 in start_thread (arg=0x7f2738204700) at pthread_create.c:333
 
#21 0x00007f274cc3993f in clone () from /lib/x86_64-linux-gnu/libc.so.6

This means that it wasn't fixed in scope of MDEV-14603; but it seems to be gone after the fix for MDEV-15070, along with other failures from MDEV-15080, so now the recommendation is to upgrade to the build #18318 or higher.

Comment by Alexander Barkov [ 2018-03-07 ]

Elena, Valerii, can we close this bug report?

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