Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.3.24, 10.4.14, 10.5.5, 10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL)
-
None
Description
One of our customer observed server crashes, when calling a function, which invokes two other functions, involving some tables and a view.
This behavior is observed at the 10.3.24, 10.4.14 and 10.5.5 (the latest releases). Also, important to note customer has provided the related functions, tables, views details, through which I can locally able to reproduce the issue at our latest releases.
Attached is the dump.sql having all related functions, tables, views. Also, attaching full error log(maria.err), all threads backtrace(mysqld_bt_all_threads.txt) output.
To reproduce:
* Install 10.3.24 or 10.4.14 or 10.5.5(latest release)
|
* restore the data - dump.sql
|
* At server.cnf put
|
lower_case_table_names=1
|
log-error=mariadb.err
|
core-file
|
* Start the server
|
* execute below SQL
|
select FN_SPM_CHK_BCD_PUBL_TEST('1', '20200910') as aaa
|
Error log output:
201007 8:56:58 [ERROR] mysqld got signal 11 ;
|
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.3.24-MariaDB-log
|
key_buffer_size=268435456
|
read_buffer_size=8388608
|
max_used_connections=1
|
max_threads=1002
|
thread_count=9
|
It is possible that mysqld could use up to
|
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 16701465 K bytes of memory
|
Hope that's ok; if not, decrease some variables in the equation.
|
|
|
Thread pointer: 0x55af048a4038
|
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 = 0x7f854c7b5d30 thread_stack 0x49000
|
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x55af0134351e]
|
/usr/sbin/mysqld(handle_fatal_signal+0x30f)[0x55af00dd8a4f]
|
sigaction.c:0(__restore_rt)[0x7f8562e16630]
|
/usr/sbin/mysqld(_ZN7Item_sp7cleanupEv+0x1b)[0x55af00df644b]
|
/usr/sbin/mysqld(_ZN12Item_func_sp7cleanupEv+0x18)[0x55af00e426f8]
|
/usr/sbin/mysqld(_Z13cleanup_itemsP4Item+0x21)[0x55af00bec581]
|
/usr/sbin/mysqld(_ZN7sp_head7executeEP3THDb+0x8d0)[0x55af00b65f40]
|
/usr/sbin/mysqld(_ZN7sp_head16execute_functionEP3THDPP4ItemjP5FieldPP11sp_rcontextP11Query_arena+0x582)[0x55af00b67ac2]
|
/usr/sbin/mysqld(_ZN7Item_sp12execute_implEP3THDPP4Itemj+0x128)[0x55af00df6618]
|
/usr/sbin/mysqld(_ZN7Item_sp7executeEP3THDPbPP4Itemj+0x21)[0x55af00df6861]
|
/usr/sbin/mysqld(_ZN12Item_func_sp7val_intEv+0x11)[0x55af00e5a271]
|
/usr/sbin/mysqld(_ZNK12Type_handler14Item_send_tinyEP4ItemP8ProtocolP8st_value+0x19)[0x55af00d2db19]
|
/usr/sbin/mysqld(_ZN8Protocol19send_result_set_rowEP4ListI4ItemE+0x13f)[0x55af00b4826f]
|
/usr/sbin/mysqld(_ZN11select_send9send_dataER4ListI4ItemE+0x53)[0x55af00bb4073]
|
/usr/sbin/mysqld(_ZN4JOIN10exec_innerEv+0xa5c)[0x55af00c51b1c]
|
/usr/sbin/mysqld(_ZN4JOIN4execEv+0x33)[0x55af00c51d63]
|
/usr/sbin/mysqld(_Z12mysql_selectP3THDP10TABLE_LISTjR4ListI4ItemEPS4_jP8st_orderS9_S7_S9_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x11a)[0x55af00c5026a]
|
/usr/sbin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x1cc)[0x55af00c50d7c]
|
/usr/sbin/mysqld(+0x4daf06)[0x55af00b00f06]
|
/usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x63ba)[0x55af00bf98ca]
|
/usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_statebb+0x36d)[0x55af00bfc63d]
|
/usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcjbb+0xfe1)[0x55af00bfded1]
|
/usr/sbin/mysqld(_Z10do_commandP3THD+0x11b)[0x55af00c0016b]
|
/usr/sbin/mysqld(_Z24do_handle_one_connectionP7CONNECT+0x1d6)[0x55af00cd6a86]
|
/usr/sbin/mysqld(handle_one_connection+0x3d)[0x55af00cd6b9d]
|
pthread_create.c:0(start_thread)[0x7f8562e0eea5]
|
/lib64/libc.so.6(clone+0x6d)[0x7f85611af8dd]
|
|
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
Query (0x55af048b1ac0): select FN_SPM_CHK_BCD_PUBL_TEST('1', '20200910') as aaa
|
Connection ID (thread ID): 11
|
Status: NOT_KILLED
|
Attachments
Issue Links
- relates to
-
-
- Stalled
-
-
-
- Closed
-
Activity
the test with no errors:
delimiter |;
|
create function f2 () returns varchar(1)
|
begin
|
DECLARE rec1 ROW TYPE OF v1;
|
SELECT z into rec1 FROM v1;
|
return 1;
|
END|
|
delimiter ;|
|
|
|
create function f1 () returns varchar(1) return f2() ;
|
create function f3 (a int) returns varchar(1) return "!";
|
create view v1 as SELECT f3(1) z;
|
|
|
select f1();
|
|
|
drop function f3;
|
drop function f2;
|
drop function f1;
|
|
|
drop view v1;
|
on 10.2 can not be reproduced because "ROW TYPE OF v1" is important but it is absent in 10.2.
I do not see how it avoud memory leak by allocatiing it only once, have you checked it?
Problem is with Item_sp (f3) created by make_view, which allocates result firld in runtime of f2 function and cleaned up when the runtime root is already freed.