[MDEV-21173] Assertion `m_thd == __null' failed in sp_head::~sp_head Created: 2019-11-28  Updated: 2022-04-05  Resolved: 2022-04-05

Status: Closed
Project: MariaDB Server
Component/s: Prepared Statements
Affects Version/s: 10.4, 10.5, 10.6, 10.7
Fix Version/s: 10.4.25, 10.5.16, 10.6.8, 10.7.4, 10.8.3, 10.9.1

Type: Bug Priority: Major
Reporter: Alice Sherepa Assignee: Dmitry Shulga
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by MDEV-23793 Assertion `m_thd == __null' failed i... Closed
Relates
relates to MDEV-22016 munmap_chunk(): invalid pointer, cras... Closed
relates to MDEV-28129 MariaDB UAF issue at lex_end_nops(LEX*) Closed

 Description   

CREATE table t1 (i int);
insert into t1 values (1),(2),(3);
 
EXECUTE IMMEDIATE "CREATE PROCEDURE p1() SELECT 1 FROM t1  PROCEDURE ANALYSE( 10, (SELECT i FROM t1));";
drop table t1;

10.4 7955e197d0ceca3108bd0d7036edaff0d7e7a9cf

Version: '10.4.11-MariaDB-debug' 
/10.4/src/sql/sp_head.cc:803: virtual sp_head::~sp_head(): Assertion `m_thd == __null' failed.
191128 17:38:08 [ERROR] mysqld got signal 6 ;
 
linux/raise.c:54(__GI_raise)[0x7f1aad83c428]
stdlib/abort.c:91(__GI_abort)[0x7f1aad83e02a]
assert/assert.c:92(__assert_fail_base)[0x7f1aad834bd7]
/lib/x86_64-linux-gnu/libc.so.6(+0x2dc82)[0x7f1aad834c82]
sql/sp_head.cc:805(sp_head::~sp_head())[0x556d9881e63e]
sql/sp_head.cc:832(sp_head::~sp_head())[0x556d9881e810]
sql/sql_lex.cc:819(lex_end_stage1(LEX*))[0x556d988dbc64]
sql/sql_prepare.cc:4085(Prepared_statement::prepare(char const*, unsigned int))[0x556d9894295b]
sql/sql_prepare.cc:4874(Prepared_statement::execute_immediate(char const*, unsigned int))[0x556d98944fc1]
sql/sql_prepare.cc:2922(mysql_sql_stmt_execute_immediate(THD*))[0x556d9893f67c]
sql/sql_parse.cc:3906(mysql_execute_command(THD*))[0x556d9891610d]
sql/sql_parse.cc:7901(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x556d98924b4b]
sql/sql_parse.cc:1844(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x556d9890fcf8]
sql/sql_parse.cc:1360(do_command(THD*))[0x556d9890e359]
sql/sql_connect.cc:1412(do_handle_one_connection(CONNECT*))[0x556d98a97e4d]
sql/sql_connect.cc:1317(handle_one_connection)[0x556d98a97b76]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba)[0x7f1aaed2b6ba]
x86_64/clone.S:111(clone)[0x7f1aad90e41d]



 Comments   
Comment by Elena Stepanova [ 2020-03-23 ]

The test case doesn't crash on a non-debug build, but it may be just luck, because it does fail on a non-debug ASAN build:

10.5 ASAN RelWithDebInfo faab0d31a

==26667==ERROR: AddressSanitizer: heap-use-after-free on address 0x62500013f628 at pc 0x56449afea805 bp 0x7f8e480724b0 sp 0x7f8e480724a8
READ of size 8 at 0x62500013f628 thread T5
    #0 0x56449afea804 in cleanup_items(Item*) /data/src/10.5-bug/sql/sql_parse.cc:1137
    #1 0x56449b03527a in Prepared_statement::cleanup_stmt() /data/src/10.5-bug/sql/sql_prepare.cc:3919
    #2 0x56449b03ca61 in Prepared_statement::prepare(char const*, unsigned int) /data/src/10.5-bug/sql/sql_prepare.cc:4112
    #3 0x56449b047677 in Prepared_statement::execute_immediate(char const*, unsigned int) /data/src/10.5-bug/sql/sql_prepare.cc:4903
    #4 0x56449b047cdf in mysql_sql_stmt_execute_immediate(THD*) /data/src/10.5-bug/sql/sql_prepare.cc:2941
    #5 0x56449aff72d6 in mysql_execute_command(THD*) /data/src/10.5-bug/sql/sql_parse.cc:3905
    #6 0x56449b00aa94 in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /data/src/10.5-bug/sql/sql_parse.cc:7926
    #7 0x56449afee230 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /data/src/10.5-bug/sql/sql_parse.cc:1840
    #8 0x56449afeab3b in do_command(THD*) /data/src/10.5-bug/sql/sql_parse.cc:1359
    #9 0x56449b295b97 in do_handle_one_connection(CONNECT*, bool) /data/src/10.5-bug/sql/sql_connect.cc:1422
    #10 0x56449b296306 in handle_one_connection /data/src/10.5-bug/sql/sql_connect.cc:1319
    #11 0x56449bb97693 in pfs_spawn_thread /data/src/10.5-bug/storage/perfschema/pfs.cc:2201
    #12 0x7f8e525114a3 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x74a3)
    #13 0x7f8e50645d0e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xe8d0e)
 
0x62500013f628 is located 7464 bytes inside of 8240-byte region [0x62500013d900,0x62500013f930)
freed by thread T5 here:
    #0 0x7f8e527e8a10 in free (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1a10)
    #1 0x56449c488a73 in free_root /data/src/10.5-bug/mysys/my_alloc.c:416
    #2 0x1f  (<unknown module>)
 
previously allocated by thread T5 here:
    #0 0x7f8e527e8d28 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
    #1 0x56449c49a523 in my_malloc /data/src/10.5-bug/mysys/my_malloc.c:88
 
Thread T5 created by T0 here:
    #0 0x7f8e52757f59 in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x30f59)
    #1 0x56449bb9790a in my_thread_create /data/src/10.5-bug/storage/perfschema/my_thread.h:34
    #2 0x56449bb9790a in pfs_spawn_thread_v1 /data/src/10.5-bug/storage/perfschema/pfs.cc:2252
 
SUMMARY: AddressSanitizer: heap-use-after-free /data/src/10.5-bug/sql/sql_parse.cc:1137 in cleanup_items(Item*)
Shadow bytes around the buggy address:
  0x0c4a8001fe70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a8001fe80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a8001fe90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a8001fea0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a8001feb0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x0c4a8001fec0: fd fd fd fd fd[fd]fd fd fd fd fd fd fd fd fd fd
  0x0c4a8001fed0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a8001fee0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a8001fef0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a8001ff00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c4a8001ff10: 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
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  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
==26667==ABORTING
200323 18:46:57 [ERROR] mysqld got signal 6 ;
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.5.2-MariaDB-log
key_buffer_size=1048576
read_buffer_size=131072
max_used_connections=1
max_threads=153
thread_count=2
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 63593 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Thread pointer: 0x62b000062218
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 = 0x7f8e48075980 thread_stack 0x5fc00
??:0(backtrace)[0x7f8e52774681]
/data/src/10.5-bug/sql/mysqld(my_print_stacktrace+0xb6)[0x56449c4a2986]
/data/src/10.5-bug/sql/mysqld(handle_fatal_signal+0x7e6)[0x56449b531b66]
??:0(__restore_rt)[0x7f8e5251b0e0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7f8e5058ffff]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f8e5059142a]
??:0(__sanitizer_cov_trace_switch)[0x7f8e52802329]
??:0(__asan_print_accumulated_stats)[0x7f8e527f79ab]
??:0(__asan_unpoison_intra_object_redzone)[0x7f8e527f1b57]
??:0(__asan_report_load8)[0x7f8e527f2398]
/data/src/10.5-bug/sql/mysqld(_Z13cleanup_itemsP4Item+0x65)[0x56449afea805]
/data/src/10.5-bug/sql/mysqld(_ZN18Prepared_statement12cleanup_stmtEv+0x6b)[0x56449b03527b]
/data/src/10.5-bug/sql/mysqld(_ZN18Prepared_statement7prepareEPKcj+0x17a2)[0x56449b03ca62]
/data/src/10.5-bug/sql/mysqld(_ZN18Prepared_statement17execute_immediateEPKcj+0x1f8)[0x56449b047678]
sql/sql_parse.cc:1136(cleanup_items(Item*))[0x56449b047ce0]
sql/sql_prepare.cc:3920(Prepared_statement::cleanup_stmt())[0x56449aff72d7]
sql/sql_prepare.cc:4113(Prepared_statement::prepare(char const*, unsigned int))[0x56449b00aa95]
sql/sql_prepare.cc:4903(Prepared_statement::execute_immediate(char const*, unsigned int))[0x56449afee231]
sql/sql_class.h:1463(Item_change_list_savepoint::rollback(Item_change_list*))[0x56449afeab3c]
sql/sql_parse.cc:5441(mysql_execute_command(THD*))[0x56449b295b98]
sql/sql_parse.cc:7943(mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool))[0x56449b296307]
sql/sql_parse.cc:1842(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool))[0x56449bb97694]
nptl/pthread_create.c:456(start_thread)[0x7f8e525114a4]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f8e50645d0f]
 
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x62b00008ddb8): CREATE PROCEDURE p1() SELECT 1 FROM t1  PROCEDURE ANALYSE( 10, (SELECT i FROM t1))
Connection ID (thread ID): 4
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
 
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Writing a core file...
Working directory at /dev/shm/var_t/mysqld.1/data
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        0                    0                    bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             128123               128123               processes 
Max open files            1024                 1024                 files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       128123               128123               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: core

Comment by Alice Sherepa [ 2022-01-27 ]

create procedure sp() select 1 procedure analyse((select 1),100);

the test also crashes on non-debug version

Version: '10.6.7-MariaDB'  
 
MariaDB [test]> create or replace procedure sp() select 1 procedure analyse((select 1),100);
ERROR 1970 (42000): PROCEDURE does not support subqueries or stored functions
MariaDB [test]> create or replace procedure sp() select 1 procedure analyse((select 1),100);
ERROR 2013 (HY000): Lost connection to server during query
 
220322 11:27:41 [ERROR] mysqld got signal 11 ;
 
Server version: 10.6.7-MariaDB
 
stack_bottom = 0x7f772495ed60 thread_stack 0x49000
mysys/stacktrace.c:213(my_print_stacktrace)[0x555f4162618e]
sql/signal_handler.cc:226(handle_fatal_signal)[0x555f40fe9657]
sigaction.c:0(__restore_rt)[0x7f773c8d03c0]
mysys/my_alloc.c:225(alloc_root)[0x555f4161a635]
sql/sql_class.h:1207(Query_arena::alloc(unsigned long))[0x555f40d986b5]
sql/sql_parse.cc:1877(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x555f40dcb7b0]
sql/sql_parse.cc:1406(do_command(THD*, bool))[0x555f40dcce83]
sql/sql_connect.cc:1418(do_handle_one_connection(CONNECT*, bool))[0x555f40ec2be7]
sql/sql_connect.cc:1318(handle_one_connection)[0x555f40ec2e84]
perfschema/pfs.cc:2204(pfs_spawn_thread)[0x555f412560cc]
nptl/pthread_create.c:478(start_thread)[0x7f773c8c4609]
??:0(clone)[0x7f773c4b0163]
 
Query (0x7f76ec022570): create or replace procedure sp() select 1 procedure analyse((select 1),100)

Comment by Oleksandr Byelkin [ 2022-04-05 ]

OK to push

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