[MDEV-32850] MariaDB got crash when call procedure - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Duplicate
Affects Version/s: 10.6.16, 10.4(EOL), 10.5, 10.6, 10.9(EOL), 10.10(EOL), 10.11, 11.0(EOL), 11.1(EOL), 11.2(EOL)
Fix Version/s: N/A
Component/s: Data Definition - Procedure
Labels:
- stored_procedures
Environment:
mariadb in docker
10.6.16-MariaDB-1:10.6.16+maria~ubu2004

Description

we notice one old issue was fixed in the latest release version,
https://jira.mariadb.org/browse/MDEV-23902

but when I bring up docker and set general_log=1, the bug trigger again.

steps:

docker pull mariadb:10.6.16

docker run --name m616 -e MYSQL_ROOT_PASSWORD=123456 -d mariadb:10.6.16

docker exec -it m616 mysql -uroot -p123456

create schema test;

use test;

set global general_log=1;

delimiter |

CREATE OR REPLACE FUNCTION cnt()

RETURNS INTEGER

NO SQL

BEGIN

   RETURN 1;

END;|

CREATE OR REPLACE PROCEDURE p1()

NO SQL

BEGIN

   DECLARE i INTEGER;

   FOR i IN 1..cnt() DO

      SELECT i;

   END FOR;

END;|

delimiter ;

CALL p1(); -- OK

CALL p1(); -- Crash

logs:

2023-11-21  1:03:06 0 [Note] mariadbd: ready for connections.

Version: '10.6.16-MariaDB-1:10.6.16+maria~ubu2004'  socket: '/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution

231121  1:03:33 [ERROR] mysqld got signal 11 ;

Sorry, we probably made a mistake, and this is a bug.

Your assistance in bug reporting will enable us to fix this for the next release.

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.6.16-MariaDB-1:10.6.16+maria~ubu2004-log source revision: b83c379420a8846ae4b28768d3c81fa354cca056

key_buffer_size=134217728

read_buffer_size=131072

max_used_connections=1

max_threads=153

thread_count=1

It is possible that mysqld could use up to

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 468005 K  bytes of memory

Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x7f44d4000c58

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 = 0x7f451813cd18 thread_stack 0x49000

Printing to addr2line failed

mariadbd(my_print_stacktrace+0x32)[0x5611310288c2]

mariadbd(handle_fatal_signal+0x475)[0x561130ae0075]

/lib/x86_64-linux-gnu/libpthread.so.0(+0x14420)[0x7f4519281420]

mariadbd(_ZN7Item_sp7cleanupEv+0x1f)[0x561130b0287f]

mariadbd(_ZN12Item_func_sp7cleanupEv+0x1c)[0x561130b504cc]

mariadbd(_Z13cleanup_itemsP4Item+0x21)[0x5611308938c1]

mariadbd(_ZN7sp_head7executeEP3THDb+0xb2d)[0x5611307e9a3d]

mariadbd(_ZN7sp_head17execute_procedureEP3THDP4ListI4ItemE+0x67a)[0x5611307eb27a]

mariadbd(+0x7b8d37)[0x561130892d37]

mariadbd(_ZN12Sql_cmd_call7executeEP3THD+0x166)[0x561130897a26]

mariadbd(_Z21mysql_execute_commandP3THDb+0x1016)[0x56113089e0f6]

mariadbd(_Z11mysql_parseP3THDPcjP12Parser_state+0x1e7)[0x56113088d847]

mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjb+0x1085)[0x56113089a025]

mariadbd(_Z10do_commandP3THDb+0x13e)[0x56113089c26e]

mariadbd(_Z24do_handle_one_connectionP7CONNECTb+0x3b7)[0x5611309b4297]

mariadbd(handle_one_connection+0x5d)[0x5611309b45ed]

mariadbd(+0xc5ba16)[0x561130d35a16]

/lib/x86_64-linux-gnu/libpthread.so.0(+0x8609)[0x7f4519275609]

/lib/x86_64-linux-gnu/libc.so.6(clone+0x43)[0x7f4518e61133]

Trying to get some variables.

Some pointers may be invalid and cause the dump to abort.

Query (0x7f44d4010990): CALL p1()

Connection ID (thread ID): 3

Status: NOT_KILLED

Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off,hash_join_cardinality=off,cset_narrowing=off

The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/ contains

information that should help you find out what is causing the crash.

Writing a core file...

Working directory at /var/lib/mysql

Resource Limits:

Limit                     Soft Limit           Hard Limit           Units

Max cpu time              unlimited            unlimited            seconds

Max file size             unlimited            unlimited            bytes

Max data size             unlimited            unlimited            bytes

Max stack size            8388608              unlimited            bytes

Max core file size        unlimited            unlimited            bytes

Max resident set          unlimited            unlimited            bytes

Max processes             unlimited            unlimited            processes

Max open files            10485760             10485760             files

Max locked memory         65536                65536                bytes

Max address space         unlimited            unlimited            bytes

Max file locks            unlimited            unlimited            locks

Max pending signals       14938                14938                signals

Max msgqueue size         819200               819200               bytes

Max nice priority         0                    0

Max realtime priority     0                    0

Max realtime timeout      unlimited            unlimited            us

Core pattern: |abrt-hook-ccpp %s %c %p %u %g %t %e %P %I %h

Kernel version: Linux version 3.10.0-1160.99.1.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Wed Sep 13 14:19:20 UTC 2023

Attachments

Issue Links

duplicates

MDEV-26115 Crash when calling stored function in FOR loop argument

Stalled

relates to

MDEV-23902 MariaDB crash on calling function

Closed

Activity

Ascending order - Click to sort in descending order

Marko Mäkelä added a comment - 2023-11-21 06:29

The stack trace contains _ZN7Item_sp7cleanupEv+0x1f, which is near the start of the following function:

void

Item_sp::cleanup()

  delete sp_result_field;

  sp_result_field= NULL;

  m_sp= NULL;

  delete func_ctx;

  func_ctx= NULL;

  free_root(&sp_mem_root, MYF(0));

  dummy_table->alias.free();

Without seeing the compiled code, I can only guess, but I think that it is plausible that this crashes in one of the delete statements when invoking an inlined destructor. Could it be that this=nullptr here? A full stack trace of the crash would help a lot. I’m not deeply familiar with Docker or the pre-made MariaDB containers. You may need https://quay.io/repository/mariadb-foundation/mariadb-debug which should allow you to obtain a resolved stack trace from GDB.

Marko Mäkelä added a comment - 2023-11-21 06:29 The stack trace contains _ZN7Item_sp7cleanupEv+0x1f , which is near the start of the following function: void Item_sp::cleanup() { delete sp_result_field; sp_result_field= NULL ; m_sp= NULL ; delete func_ctx; func_ctx= NULL ; free_root(&sp_mem_root, MYF(0)); dummy_table->alias. free (); } Without seeing the compiled code, I can only guess, but I think that it is plausible that this crashes in one of the delete statements when invoking an inlined destructor. Could it be that this=nullptr here? A full stack trace of the crash would help a lot. I’m not deeply familiar with Docker or the pre-made MariaDB containers. You may need https://quay.io/repository/mariadb-foundation/mariadb-debug which should allow you to obtain a resolved stack trace from GDB.

Alice Sherepa added a comment - 2023-11-21 08:34 - edited

Thank you for the report!
I repeated as described on 10.4-11.2. This is the same as MDEV-26115

Version: '10.4.33-MariaDB-debug-log'  0381197855c58e339ab5034b871ea9c0c2d61522

=================================================================

==1304488==ERROR: AddressSanitizer: heap-use-after-free on address 0x625000179cf8 at pc 0x55c63ff39140 bp 0x7f5d6f5b9780 sp 0x7f5d6f5b9770

READ of size 8 at 0x625000179cf8 thread T31

    #0 0x55c63ff3913f in Item_sp::cleanup() /10.4/src/sql/item.cc:2727

    #1 0x55c640072ebf in Item_func_sp::cleanup() /10.4/src/sql/item_func.cc:6419

    #2 0x55c63f6fad40 in cleanup_items(Item*) /10.4/src/sql/sql_parse.cc:1135

    #3 0x55c63f4b196f in sp_head::execute(THD*, bool) /10.4/src/sql/sp_head.cc:1445

    #4 0x55c63f4b75c7 in sp_head::execute_procedure(THD*, List<Item>*) /10.4/src/sql/sp_head.cc:2407

    #5 0x55c63f706e3f in do_execute_sp /10.4/src/sql/sql_parse.cc:3064

    #6 0x55c63f708a39 in Sql_cmd_call::execute(THD*) /10.4/src/sql/sql_parse.cc:3306

    #7 0x55c63f71db9b in mysql_execute_command(THD*) /10.4/src/sql/sql_parse.cc:6218

    #8 0x55c63f729786 in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /10.4/src/sql/sql_parse.cc:8014

    #9 0x55c63f6ffb12 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /10.4/src/sql/sql_parse.cc:1857

    #10 0x55c63f6fc63d in do_command(THD*) /10.4/src/sql/sql_parse.cc:1378

    #11 0x55c63fb10f65 in do_handle_one_connection(CONNECT*) /10.4/src/sql/sql_connect.cc:1419

    #12 0x55c63fb10809 in handle_one_connection /10.4/src/sql/sql_connect.cc:1323

    #13 0x55c6407ae5eb in pfs_spawn_thread /10.4/src/storage/perfschema/pfs.cc:1869

    #14 0x7f5d86526608 in start_thread /build/glibc-BHL3KM/glibc-2.31/nptl/pthread_create.c:477

    #15 0x7f5d860f7132 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x11f132)

0x625000179cf8 is located 1016 bytes inside of 8268-byte region [0x625000179900,0x62500017b94c)

freed by thread T31 here:

    #0 0x7f5d86b2440f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:122

    #1 0x55c641335f0b in free_memory /10.4/src/mysys/safemalloc.c:279

    #2 0x55c6413354c7 in sf_free /10.4/src/mysys/safemalloc.c:197

    #3 0x55c6413040bf in my_free /10.4/src/mysys/my_malloc.c:222

    #4 0x55c6412e0e05 in free_root /10.4/src/mysys/my_alloc.c:437

    #5 0x55c63f4b1a68 in sp_head::execute(THD*, bool) /10.4/src/sql/sp_head.cc:1459

    #6 0x55c63f4b75c7 in sp_head::execute_procedure(THD*, List<Item>*) /10.4/src/sql/sp_head.cc:2407

    #7 0x55c63f706e3f in do_execute_sp /10.4/src/sql/sql_parse.cc:3064

    #8 0x55c63f708a39 in Sql_cmd_call::execute(THD*) /10.4/src/sql/sql_parse.cc:3306

    #9 0x55c63f71db9b in mysql_execute_command(THD*) /10.4/src/sql/sql_parse.cc:6218

    #10 0x55c63f729786 in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /10.4/src/sql/sql_parse.cc:8014

    #11 0x55c63f6ffb12 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /10.4/src/sql/sql_parse.cc:1857

    #12 0x55c63f6fc63d in do_command(THD*) /10.4/src/sql/sql_parse.cc:1378

    #13 0x55c63fb10f65 in do_handle_one_connection(CONNECT*) /10.4/src/sql/sql_connect.cc:1419

    #14 0x55c63fb10809 in handle_one_connection /10.4/src/sql/sql_connect.cc:1323

    #15 0x55c6407ae5eb in pfs_spawn_thread /10.4/src/storage/perfschema/pfs.cc:1869

    #16 0x7f5d86526608 in start_thread /build/glibc-BHL3KM/glibc-2.31/nptl/pthread_create.c:477

previously allocated by thread T31 here:

    #0 0x7f5d86b24808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144

    #1 0x55c641334e7b in sf_malloc /10.4/src/mysys/safemalloc.c:118

    #2 0x55c6413035c8 in my_malloc /10.4/src/mysys/my_malloc.c:101

    #3 0x55c6412dfc0b in alloc_root /10.4/src/mysys/my_alloc.c:258

    #4 0x55c63f41b733 in Query_arena::alloc(unsigned long) /10.4/src/sql/sql_class.h:1122

    #5 0x55c63f582e84 in lock_tables(THD*, TABLE_LIST*, unsigned int, unsigned int) /10.4/src/sql/sql_base.cc:5557

    #6 0x55c63f581c8b in open_and_lock_tables(THD*, DDL_options_st const&, TABLE_LIST*, bool, unsigned int, Prelocking_strategy*) /10.4/src/sql/sql_base.cc:5353

    #7 0x55c63f4d8cfa in open_and_lock_tables(THD*, TABLE_LIST*, bool, unsigned int) /10.4/src/sql/sql_base.h:503

    #8 0x55c63f59b004 in open_system_tables_for_read(THD*, TABLE_LIST*, Open_tables_backup*) /10.4/src/sql/sql_base.cc:9199

    #9 0x55c640328209 in open_proc_table_for_read(THD*, Open_tables_backup*) /10.4/src/sql/sp.cc:487

    #10 0x55c640329ee8 in Sp_handler::db_find_routine(THD*, Database_qualified_name const*, sp_head**) const /10.4/src/sql/sp.cc:697

    #11 0x55c64032aa08 in Sp_handler::db_find_and_cache_routine(THD*, Database_qualified_name const*, sp_head**) const /10.4/src/sql/sp.cc:768

    #12 0x55c640339943 in Sp_handler::sp_cache_routine(THD*, Database_qualified_name const*, bool, sp_head**) const /10.4/src/sql/sp.cc:2795

    #13 0x55c6403394cd in Sroutine_hash_entry::sp_cache_routine(THD*, bool, sp_head**) const /10.4/src/sql/sp.cc:2748

    #14 0x55c63f577fd2 in open_and_process_routine /10.4/src/sql/sql_base.cc:3562

    #15 0x55c63f57cce5 in open_tables(THD*, DDL_options_st const&, TABLE_LIST**, unsigned int*, unsigned int, Prelocking_strategy*) /10.4/src/sql/sql_base.cc:4469

    #16 0x55c63f581b6f in open_and_lock_tables(THD*, DDL_options_st const&, TABLE_LIST*, bool, unsigned int, Prelocking_strategy*) /10.4/src/sql/sql_base.cc:5344

    #17 0x55c63f4d8cfa in open_and_lock_tables(THD*, TABLE_LIST*, bool, unsigned int) /10.4/src/sql/sql_base.h:503

    #18 0x55c63f4bfa60 in sp_instr::exec_open_and_lock_tables(THD*, TABLE_LIST*) /10.4/src/sql/sp_head.cc:3609

    #19 0x55c63f4bef1a in sp_lex_keeper::reset_lex_and_exec_core(THD*, unsigned int*, bool, sp_instr*) /10.4/src/sql/sp_head.cc:3487

    #20 0x55c63f4c0b50 in sp_instr_set::execute(THD*, unsigned int*) /10.4/src/sql/sp_head.cc:3778

    #21 0x55c63f4b13a2 in sp_head::execute(THD*, bool) /10.4/src/sql/sp_head.cc:1372

    #22 0x55c63f4b75c7 in sp_head::execute_procedure(THD*, List<Item>*) /10.4/src/sql/sp_head.cc:2407

    #23 0x55c63f706e3f in do_execute_sp /10.4/src/sql/sql_parse.cc:3064

    #24 0x55c63f708a39 in Sql_cmd_call::execute(THD*) /10.4/src/sql/sql_parse.cc:3306

    #25 0x55c63f71db9b in mysql_execute_command(THD*) /10.4/src/sql/sql_parse.cc:6218

    #26 0x55c63f729786 in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /10.4/src/sql/sql_parse.cc:8014

    #27 0x55c63f6ffb12 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /10.4/src/sql/sql_parse.cc:1857

    #28 0x55c63f6fc63d in do_command(THD*) /10.4/src/sql/sql_parse.cc:1378

    #29 0x55c63fb10f65 in do_handle_one_connection(CONNECT*) /10.4/src/sql/sql_connect.cc:1419

Thread T31 created by T0 here:

    #0 0x7f5d86a51815 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cc:208

    #1 0x55c6407ae9dc in spawn_thread_v1 /10.4/src/storage/perfschema/pfs.cc:1919

    #2 0x55c63f3f4f71 in inline_mysql_thread_create /10.4/src/include/mysql/psi/mysql_thread.h:1275

    #3 0x55c63f40d161 in create_thread_to_handle_connection(CONNECT*) /10.4/src/sql/mysqld.cc:6296

    #4 0x55c63f40d8fc in create_new_thread(CONNECT*) /10.4/src/sql/mysqld.cc:6366

    #5 0x55c63f40dde2 in handle_accepted_socket(st_mysql_socket, st_mysql_socket) /10.4/src/sql/mysqld.cc:6464

    #6 0x55c63f40ec9e in handle_connections_sockets() /10.4/src/sql/mysqld.cc:6622

    #7 0x55c63f40c866 in mysqld_main(int, char**) /10.4/src/sql/mysqld.cc:5954

    #8 0x55c63f3f2f3c in main /10.4/src/sql/main.cc:25

    #9 0x7f5d85ffc082 in __libc_start_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: heap-use-after-free /10.4/src/sql/item.cc:2727 in Item_sp::cleanup()

Shadow bytes around the buggy address:

  0x0c4a80027340: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd

  0x0c4a80027350: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd

  0x0c4a80027360: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd

  0x0c4a80027370: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd

  0x0c4a80027380: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd

=>0x0c4a80027390: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd[fd]

  0x0c4a800273a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd

  0x0c4a800273b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd

  0x0c4a800273c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd

  0x0c4a800273d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd

  0x0c4a800273e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd

Shadow byte legend (one shadow byte represents 8 application bytes):

  Addressable:           00

  Partially addressable: 01 02 03 04 05 06 07

  Heap left redzone:       fa

  Freed heap region:       fd

  Stack left redzone:      f1

  Stack mid redzone:       f2

  Stack right redzone:     f3

  Stack after return:      f5

  Stack use after scope:   f8

  Global redzone:          f9

  Global init order:       f6

  Poisoned by user:        f7

  Container overflow:      fc

  Array cookie:            ac

  Intra object redzone:    bb

  ASan internal:           fe

  Left alloca redzone:     ca

  Right alloca redzone:    cb

  Shadow gap:              cc

==1304488==ABORTING

----------SERVER LOG END-------------

Alice Sherepa added a comment - 2023-11-21 08:34 - edited Thank you for the report! I repeated as described on 10.4-11.2. This is the same as MDEV-26115 Version: '10.4.33-MariaDB-debug-log' 0381197855c58e339ab5034b871ea9c0c2d61522 ================================================================= ==1304488==ERROR: AddressSanitizer: heap-use-after-free on address 0x625000179cf8 at pc 0x55c63ff39140 bp 0x7f5d6f5b9780 sp 0x7f5d6f5b9770 READ of size 8 at 0x625000179cf8 thread T31 #0 0x55c63ff3913f in Item_sp::cleanup() /10.4/src/sql/item.cc:2727 #1 0x55c640072ebf in Item_func_sp::cleanup() /10.4/src/sql/item_func.cc:6419 #2 0x55c63f6fad40 in cleanup_items(Item*) /10.4/src/sql/sql_parse.cc:1135 #3 0x55c63f4b196f in sp_head::execute(THD*, bool) /10.4/src/sql/sp_head.cc:1445 #4 0x55c63f4b75c7 in sp_head::execute_procedure(THD*, List<Item>*) /10.4/src/sql/sp_head.cc:2407 #5 0x55c63f706e3f in do_execute_sp /10.4/src/sql/sql_parse.cc:3064 #6 0x55c63f708a39 in Sql_cmd_call::execute(THD*) /10.4/src/sql/sql_parse.cc:3306 #7 0x55c63f71db9b in mysql_execute_command(THD*) /10.4/src/sql/sql_parse.cc:6218 #8 0x55c63f729786 in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /10.4/src/sql/sql_parse.cc:8014 #9 0x55c63f6ffb12 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /10.4/src/sql/sql_parse.cc:1857 #10 0x55c63f6fc63d in do_command(THD*) /10.4/src/sql/sql_parse.cc:1378 #11 0x55c63fb10f65 in do_handle_one_connection(CONNECT*) /10.4/src/sql/sql_connect.cc:1419 #12 0x55c63fb10809 in handle_one_connection /10.4/src/sql/sql_connect.cc:1323 #13 0x55c6407ae5eb in pfs_spawn_thread /10.4/src/storage/perfschema/pfs.cc:1869 #14 0x7f5d86526608 in start_thread /build/glibc-BHL3KM/glibc-2.31/nptl/pthread_create.c:477 #15 0x7f5d860f7132 in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x11f132) 0x625000179cf8 is located 1016 bytes inside of 8268-byte region [0x625000179900,0x62500017b94c) freed by thread T31 here: #0 0x7f5d86b2440f in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:122 #1 0x55c641335f0b in free_memory /10.4/src/mysys/safemalloc.c:279 #2 0x55c6413354c7 in sf_free /10.4/src/mysys/safemalloc.c:197 #3 0x55c6413040bf in my_free /10.4/src/mysys/my_malloc.c:222 #4 0x55c6412e0e05 in free_root /10.4/src/mysys/my_alloc.c:437 #5 0x55c63f4b1a68 in sp_head::execute(THD*, bool) /10.4/src/sql/sp_head.cc:1459 #6 0x55c63f4b75c7 in sp_head::execute_procedure(THD*, List<Item>*) /10.4/src/sql/sp_head.cc:2407 #7 0x55c63f706e3f in do_execute_sp /10.4/src/sql/sql_parse.cc:3064 #8 0x55c63f708a39 in Sql_cmd_call::execute(THD*) /10.4/src/sql/sql_parse.cc:3306 #9 0x55c63f71db9b in mysql_execute_command(THD*) /10.4/src/sql/sql_parse.cc:6218 #10 0x55c63f729786 in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /10.4/src/sql/sql_parse.cc:8014 #11 0x55c63f6ffb12 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /10.4/src/sql/sql_parse.cc:1857 #12 0x55c63f6fc63d in do_command(THD*) /10.4/src/sql/sql_parse.cc:1378 #13 0x55c63fb10f65 in do_handle_one_connection(CONNECT*) /10.4/src/sql/sql_connect.cc:1419 #14 0x55c63fb10809 in handle_one_connection /10.4/src/sql/sql_connect.cc:1323 #15 0x55c6407ae5eb in pfs_spawn_thread /10.4/src/storage/perfschema/pfs.cc:1869 #16 0x7f5d86526608 in start_thread /build/glibc-BHL3KM/glibc-2.31/nptl/pthread_create.c:477 previously allocated by thread T31 here: #0 0x7f5d86b24808 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144 #1 0x55c641334e7b in sf_malloc /10.4/src/mysys/safemalloc.c:118 #2 0x55c6413035c8 in my_malloc /10.4/src/mysys/my_malloc.c:101 #3 0x55c6412dfc0b in alloc_root /10.4/src/mysys/my_alloc.c:258 #4 0x55c63f41b733 in Query_arena::alloc(unsigned long) /10.4/src/sql/sql_class.h:1122 #5 0x55c63f582e84 in lock_tables(THD*, TABLE_LIST*, unsigned int, unsigned int) /10.4/src/sql/sql_base.cc:5557 #6 0x55c63f581c8b in open_and_lock_tables(THD*, DDL_options_st const&, TABLE_LIST*, bool, unsigned int, Prelocking_strategy*) /10.4/src/sql/sql_base.cc:5353 #7 0x55c63f4d8cfa in open_and_lock_tables(THD*, TABLE_LIST*, bool, unsigned int) /10.4/src/sql/sql_base.h:503 #8 0x55c63f59b004 in open_system_tables_for_read(THD*, TABLE_LIST*, Open_tables_backup*) /10.4/src/sql/sql_base.cc:9199 #9 0x55c640328209 in open_proc_table_for_read(THD*, Open_tables_backup*) /10.4/src/sql/sp.cc:487 #10 0x55c640329ee8 in Sp_handler::db_find_routine(THD*, Database_qualified_name const*, sp_head**) const /10.4/src/sql/sp.cc:697 #11 0x55c64032aa08 in Sp_handler::db_find_and_cache_routine(THD*, Database_qualified_name const*, sp_head**) const /10.4/src/sql/sp.cc:768 #12 0x55c640339943 in Sp_handler::sp_cache_routine(THD*, Database_qualified_name const*, bool, sp_head**) const /10.4/src/sql/sp.cc:2795 #13 0x55c6403394cd in Sroutine_hash_entry::sp_cache_routine(THD*, bool, sp_head**) const /10.4/src/sql/sp.cc:2748 #14 0x55c63f577fd2 in open_and_process_routine /10.4/src/sql/sql_base.cc:3562 #15 0x55c63f57cce5 in open_tables(THD*, DDL_options_st const&, TABLE_LIST**, unsigned int*, unsigned int, Prelocking_strategy*) /10.4/src/sql/sql_base.cc:4469 #16 0x55c63f581b6f in open_and_lock_tables(THD*, DDL_options_st const&, TABLE_LIST*, bool, unsigned int, Prelocking_strategy*) /10.4/src/sql/sql_base.cc:5344 #17 0x55c63f4d8cfa in open_and_lock_tables(THD*, TABLE_LIST*, bool, unsigned int) /10.4/src/sql/sql_base.h:503 #18 0x55c63f4bfa60 in sp_instr::exec_open_and_lock_tables(THD*, TABLE_LIST*) /10.4/src/sql/sp_head.cc:3609 #19 0x55c63f4bef1a in sp_lex_keeper::reset_lex_and_exec_core(THD*, unsigned int*, bool, sp_instr*) /10.4/src/sql/sp_head.cc:3487 #20 0x55c63f4c0b50 in sp_instr_set::execute(THD*, unsigned int*) /10.4/src/sql/sp_head.cc:3778 #21 0x55c63f4b13a2 in sp_head::execute(THD*, bool) /10.4/src/sql/sp_head.cc:1372 #22 0x55c63f4b75c7 in sp_head::execute_procedure(THD*, List<Item>*) /10.4/src/sql/sp_head.cc:2407 #23 0x55c63f706e3f in do_execute_sp /10.4/src/sql/sql_parse.cc:3064 #24 0x55c63f708a39 in Sql_cmd_call::execute(THD*) /10.4/src/sql/sql_parse.cc:3306 #25 0x55c63f71db9b in mysql_execute_command(THD*) /10.4/src/sql/sql_parse.cc:6218 #26 0x55c63f729786 in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /10.4/src/sql/sql_parse.cc:8014 #27 0x55c63f6ffb12 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /10.4/src/sql/sql_parse.cc:1857 #28 0x55c63f6fc63d in do_command(THD*) /10.4/src/sql/sql_parse.cc:1378 #29 0x55c63fb10f65 in do_handle_one_connection(CONNECT*) /10.4/src/sql/sql_connect.cc:1419 Thread T31 created by T0 here: #0 0x7f5d86a51815 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cc:208 #1 0x55c6407ae9dc in spawn_thread_v1 /10.4/src/storage/perfschema/pfs.cc:1919 #2 0x55c63f3f4f71 in inline_mysql_thread_create /10.4/src/include/mysql/psi/mysql_thread.h:1275 #3 0x55c63f40d161 in create_thread_to_handle_connection(CONNECT*) /10.4/src/sql/mysqld.cc:6296 #4 0x55c63f40d8fc in create_new_thread(CONNECT*) /10.4/src/sql/mysqld.cc:6366 #5 0x55c63f40dde2 in handle_accepted_socket(st_mysql_socket, st_mysql_socket) /10.4/src/sql/mysqld.cc:6464 #6 0x55c63f40ec9e in handle_connections_sockets() /10.4/src/sql/mysqld.cc:6622 #7 0x55c63f40c866 in mysqld_main(int, char**) /10.4/src/sql/mysqld.cc:5954 #8 0x55c63f3f2f3c in main /10.4/src/sql/main.cc:25 #9 0x7f5d85ffc082 in __libc_start_main ../csu/libc-start.c:308 SUMMARY: AddressSanitizer: heap-use-after-free /10.4/src/sql/item.cc:2727 in Item_sp::cleanup() Shadow bytes around the buggy address: 0x0c4a80027340: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a80027350: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a80027360: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a80027370: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a80027380: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd =>0x0c4a80027390: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd[fd] 0x0c4a800273a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a800273b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a800273c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a800273d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a800273e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==1304488==ABORTING ----------SERVER LOG END-------------

Shawn Yan added a comment - 2023-11-21 08:57

hi, Alice,
plz note that, when I send "call p1()" in 10.6.16， DB runs normal,
but, when I send "set global general_log=1" first, then "call p1", db got crash,
that's not exactly the same。

Shawn Yan added a comment - 2023-11-21 08:57 hi, Alice, plz note that, when I send "call p1()" in 10.6.16， DB runs normal, but, when I send "set global general_log=1" first, then "call p1", db got crash, that's not exactly the same。

Alice Sherepa added a comment - 2023-11-21 11:29

shawn2016 It is also repeatable without setting general_log=1, just after the second execution of the procedure. But sure after MDEV-26115 will be patched - this test should be checked again.

MariaDB [test]> select version();

+-----------------+

| version()       |

+-----------------+

| 10.6.16-MariaDB |

+-----------------+

1 row in set (0,000 sec)

MariaDB [test]> delimiter |

MariaDB [test]> CREATE OR REPLACE FUNCTION cnt()

    -> RETURNS INTEGER

    -> NO SQL

    -> BEGIN

    ->    RETURN 1;

    -> END;|

Query OK, 0 rows affected (0,014 sec)

MariaDB [test]> CREATE OR REPLACE PROCEDURE p1()

    -> NO SQL

    -> BEGIN

    ->    DECLARE i INTEGER;

    ->    FOR i IN 1..cnt() DO

    ->       SELECT i;

    ->    END FOR;

    -> END;|

Query OK, 0 rows affected (0,020 sec)

MariaDB [test]> CALL p1()|

+---+

| i |

+---+

| 1 |

+---+

1 row in set (0,001 sec)

Query OK, 0 rows affected (0,001 sec)

MariaDB [test]> CALL p1()|

ERROR 2013 (HY000): Lost connection to server during query

231121 12:26:33 [ERROR] mysqld got signal 11 ;

Server version: 10.6.16-MariaDB source revision: b83c379420a8846ae4b28768d3c81fa354cca056

sql/signal_handler.cc:238(handle_fatal_signal)[0x55bd6f81ed67]

sigaction.c:0(__restore_rt)[0x7fa891416420]

sql/item.cc:2815(Item_sp::cleanup())[0x55bd6f83f90b]

sql/item_func.h:141(Item_func::cleanup())[0x55bd6f88d068]

sql/sql_parse.cc:1127(cleanup_items(Item*))[0x55bd6f5e6631]

sql/sp_head.cc:1528(sp_head::execute(THD*, bool))[0x55bd6f54c2dc]

psi/mysql_sp.h:79(sp_head::execute_procedure(THD*, List<Item>*))[0x55bd6f54db5f]

sql/sql_parse.cc:3041(do_execute_sp(THD*, sp_head*))[0x55bd6f5e597a]

sql/sql_parse.cc:3284(Sql_cmd_call::execute(THD*))[0x55bd6f5e81ba]

sql/sql_parse.cc:6026(mysql_execute_command(THD*, bool))[0x55bd6f5ef95a]

sql/sql_parse.cc:8052(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x55bd6f5f371b]

sql/sql_parse.cc:1957(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x55bd6f5f5b50]

sql/sql_parse.cc:1411(do_command(THD*, bool))[0x55bd6f5f7073]

sql/sql_connect.cc:1416(do_handle_one_connection(CONNECT*, bool))[0x55bd6f6f4f87]

sql/sql_connect.cc:1324(handle_one_connection)[0x55bd6f6f5224]

perfschema/pfs.cc:2204(pfs_spawn_thread)[0x55bd6fa97c8c]

nptl/pthread_create.c:478(start_thread)[0x7fa89140a609]

Query (0x7fa8400131a0): CALL p1()

Alice Sherepa added a comment - 2023-11-21 11:29 shawn2016 It is also repeatable without setting general_log=1, just after the second execution of the procedure. But sure after MDEV-26115 will be patched - this test should be checked again. MariaDB [test]> select version(); +-----------------+ | version() | +-----------------+ | 10.6.16-MariaDB | +-----------------+ 1 row in set (0,000 sec) MariaDB [test]> delimiter | MariaDB [test]> CREATE OR REPLACE FUNCTION cnt() -> RETURNS INTEGER -> NO SQL -> BEGIN -> RETURN 1; -> END;| Query OK, 0 rows affected (0,014 sec) MariaDB [test]> CREATE OR REPLACE PROCEDURE p1() -> NO SQL -> BEGIN -> DECLARE i INTEGER; -> FOR i IN 1..cnt() DO -> SELECT i; -> END FOR; -> END;| Query OK, 0 rows affected (0,020 sec) MariaDB [test]> CALL p1()| +---+ | i | +---+ | 1 | +---+ 1 row in set (0,001 sec) Query OK, 0 rows affected (0,001 sec) MariaDB [test]> CALL p1()| ERROR 2013 (HY000): Lost connection to server during query 231121 12:26:33 [ERROR] mysqld got signal 11 ; Server version: 10.6.16-MariaDB source revision: b83c379420a8846ae4b28768d3c81fa354cca056 sql/signal_handler.cc:238(handle_fatal_signal)[0x55bd6f81ed67] sigaction.c:0(__restore_rt)[0x7fa891416420] sql/item.cc:2815(Item_sp::cleanup())[0x55bd6f83f90b] sql/item_func.h:141(Item_func::cleanup())[0x55bd6f88d068] sql/sql_parse.cc:1127(cleanup_items(Item*))[0x55bd6f5e6631] sql/sp_head.cc:1528(sp_head::execute(THD*, bool))[0x55bd6f54c2dc] psi/mysql_sp.h:79(sp_head::execute_procedure(THD*, List<Item>*))[0x55bd6f54db5f] sql/sql_parse.cc:3041(do_execute_sp(THD*, sp_head*))[0x55bd6f5e597a] sql/sql_parse.cc:3284(Sql_cmd_call::execute(THD*))[0x55bd6f5e81ba] sql/sql_parse.cc:6026(mysql_execute_command(THD*, bool))[0x55bd6f5ef95a] sql/sql_parse.cc:8052(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x55bd6f5f371b] sql/sql_parse.cc:1957(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x55bd6f5f5b50] sql/sql_parse.cc:1411(do_command(THD*, bool))[0x55bd6f5f7073] sql/sql_connect.cc:1416(do_handle_one_connection(CONNECT*, bool))[0x55bd6f6f4f87] sql/sql_connect.cc:1324(handle_one_connection)[0x55bd6f6f5224] perfschema/pfs.cc:2204(pfs_spawn_thread)[0x55bd6fa97c8c] nptl/pthread_create.c:478(start_thread)[0x7fa89140a609] Query (0x7fa8400131a0): CALL p1()

People

Assignee:: Unassigned

Reporter:: Shawn Yan

Votes:: 0 Vote for this issue

Watchers:: 3 Start watching this issue

Dates

Created:: 2023-11-21 01:19

Updated:: 2023-11-21 11:29

Resolved:: 2023-11-21 08:46

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server