[MDEV-23837] ASAN requested allocation size exceeds maximum supported size or Valgrind Argument 'size' of function malloc has a fishy value in JOIN_CACHE::alloc_buffer Created: 2020-09-28  Updated: 2021-08-30

Status: Open
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.4, 10.5, 10.6
Fix Version/s: 10.4, 10.5, 10.6

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Sergei Petrunia
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If the problem is limited to the low value of join_buffer_space_limit, it can be considered a corner case; but it could be scalable, so it is worth checking at least.

CREATE TABLE t1 (a varchar(10)) ENGINE=MyISAM;
 
INSERT INTO t1 VALUES ('foo'),('bar');
 
 
 
CREATE TABLE t2 (b varchar(1024)) ENGINE=MyISAM;
 
INSERT INTO t2 VALUES ('baz');
 
 
 
CREATE TABLE t3 (c int) ENGINE=MyISAM;
 
INSERT INTO t3 VALUES (1),(2);
 
 
 
CREATE TABLE t4 (d int, e varchar(1024)) ENGINE=MyISAM;
 
INSERT INTO t4 VALUES (1,'foo'),(2,'bar');
 
 
 
CREATE TABLE t5 (f int) ENGINE=MyISAM;
 
INSERT INTO t5 VALUES (3);
 
 
 
CREATE TABLE t6 (g varchar(1024)) ENGINE=MyISAM;
 
INSERT INTO t6 VALUES ('qux'),('foobar');
 
 
 
SET SESSION join_buffer_space_limit= 16384;
 
SET SESSION join_cache_level= 5;
 
 
 
SELECT STRAIGHT_JOIN t6.* FROM t1 LEFT JOIN t2 ON t2.b = t1.a LEFT JOIN t3 JOIN t4 ON t3.c = t4.d JOIN t5 ON t4.d = t5.f ON t2.b = t4.e LEFT JOIN t6 ON t6.g = t4.e;
 
 
 
# Cleanup
 
DROP TABLE t1, t2, t3, t4, t5, t6;

10.4 e8b05ce5

 
==1872015==ERROR: AddressSanitizer: requested allocation size 0xffffffffffffffd4 (0x7d8 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x10000000000 (thread T5)
 
    #0 0x7fc320717bc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
 
    #1 0x55917545dc44 in sf_malloc /data/src/10.4/mysys/safemalloc.c:118
 
    #2 0x55917542becb in my_malloc /data/src/10.4/mysys/my_malloc.c:101
 
    #3 0x559173b5f427 in JOIN_CACHE::alloc_buffer() /data/src/10.4/sql/sql_join_cache.cc:940
 
    #4 0x559173b5fc20 in JOIN_CACHE::init(bool) /data/src/10.4/sql/sql_join_cache.cc:1072
 
    #5 0x559173b69937 in JOIN_CACHE_HASHED::init(bool) /data/src/10.4/sql/sql_join_cache.cc:2687
 
    #6 0x559173b6e079 in JOIN_CACHE_BNLH::init(bool) /data/src/10.4/sql/sql_join_cache.cc:3814
 
    #7 0x559173791c0d in JOIN::init_join_caches() /data/src/10.4/sql/sql_select.cc:1782
 
    #8 0x55917379eb64 in JOIN::optimize_stage2() /data/src/10.4/sql/sql_select.cc:3011
 
    #9 0x55917379735d in JOIN::optimize_inner() /data/src/10.4/sql/sql_select.cc:2294
 
    #10 0x559173790041 in JOIN::optimize() /data/src/10.4/sql/sql_select.cc:1615
 
    #11 0x5591737b0b15 in mysql_select(THD*, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) /data/src/10.4/sql/sql_select.cc:4681
 
    #12 0x55917378249f in handle_select(THD*, LEX*, select_result*, unsigned long) /data/src/10.4/sql/sql_select.cc:410
 
    #13 0x5591736f3621 in execute_sqlcom_select /data/src/10.4/sql/sql_parse.cc:6355
 
    #14 0x5591736e0eef in mysql_execute_command(THD*) /data/src/10.4/sql/sql_parse.cc:3889
 
    #15 0x5591736fc9ef in mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) /data/src/10.4/sql/sql_parse.cc:7896
 
    #16 0x5591736d3aad in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) /data/src/10.4/sql/sql_parse.cc:1834
 
    #17 0x5591736d0579 in do_command(THD*) /data/src/10.4/sql/sql_parse.cc:1352
 
    #18 0x559173abc9f6 in do_handle_one_connection(CONNECT*) /data/src/10.4/sql/sql_connect.cc:1412
 
    #19 0x559173abc29a in handle_one_connection /data/src/10.4/sql/sql_connect.cc:1316
 
    #20 0x55917515106e in pfs_spawn_thread /data/src/10.4/storage/perfschema/pfs.cc:1869
 
    #21 0x7fc320521608 in start_thread /build/glibc-ZN95T4/glibc-2.31/nptl/pthread_create.c:477
 
 
 
==1872015==HINT: if you don't care about these errors you may set allocator_may_return_null=1
 
SUMMARY: AddressSanitizer: allocation-size-too-big (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8) in malloc
 
Thread T5 created by T0 here:
 
    #0 0x7fc320644805 in pthread_create (/lib/x86_64-linux-gnu/libasan.so.5+0x3a805)
 
    #1 0x55917515145f in spawn_thread_v1 /data/src/10.4/storage/perfschema/pfs.cc:1919
 
    #2 0x5591733ddf88 in inline_mysql_thread_create /data/src/10.4/include/mysql/psi/mysql_thread.h:1275
 
    #3 0x5591733f5976 in create_thread_to_handle_connection(CONNECT*) /data/src/10.4/sql/mysqld.cc:6259
 
    #4 0x5591733f6107 in create_new_thread(CONNECT*) /data/src/10.4/sql/mysqld.cc:6329
 
    #5 0x5591733f65e6 in handle_accepted_socket(st_mysql_socket, st_mysql_socket) /data/src/10.4/sql/mysqld.cc:6427
 
    #6 0x5591733f7477 in handle_connections_sockets() /data/src/10.4/sql/mysqld.cc:6585
 
    #7 0x5591733f5095 in mysqld_main(int, char**) /data/src/10.4/sql/mysqld.cc:5917
 
    #8 0x5591733dbf4c in main /data/src/10.4/sql/main.cc:25
 
    #9 0x7fc31fffa0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
 
 
 
==1872015==ABORTING

10.4 valgrind 29847a37

 
==1871905== Thread 6:
 
==1871905== Argument 'size' of function malloc has a fishy (possibly negative) value: -152
 
==1871905==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
 
==1871905==    by 0x168728E: my_malloc (my_malloc.c:101)
 
==1871905==    by 0xB2CEB5: JOIN_CACHE::alloc_buffer() (sql_join_cache.cc:940)
 
==1871905==    by 0xB2D26E: JOIN_CACHE::init(bool) (sql_join_cache.cc:1072)
 
==1871905==    by 0xB30AAA: JOIN_CACHE_HASHED::init(bool) (sql_join_cache.cc:2687)
 
==1871905==    by 0xB323B3: JOIN_CACHE_BNLH::init(bool) (sql_join_cache.cc:3814)
 
==1871905==    by 0x99ACB8: JOIN::init_join_caches() (sql_select.cc:1782)
 
==1871905==    by 0x99F4BA: JOIN::optimize_stage2() (sql_select.cc:3011)
 
==1871905==    by 0x99CC2D: JOIN::optimize_inner() (sql_select.cc:2294)
 
==1871905==    by 0x99A3E2: JOIN::optimize() (sql_select.cc:1615)
 
==1871905==    by 0x9A5A54: mysql_select(THD*, TABLE_LIST*, unsigned int, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) (sql_select.cc:4681)
 
==1871905==    by 0x995354: handle_select(THD*, LEX*, select_result*, unsigned long) (sql_select.cc:410)
 
==1871905==    by 0x95A4F9: execute_sqlcom_select(THD*, TABLE_LIST*) (sql_parse.cc:6355)
 
==1871905==    by 0x950A49: mysql_execute_command(THD*) (sql_parse.cc:3889)
 
==1871905==    by 0x95E504: mysql_parse(THD*, char*, unsigned int, Parser_state*, bool, bool) (sql_parse.cc:7896)
 
==1871905==    by 0x94A8C3: dispatch_command(enum_server_command, THD*, char*, unsigned int, bool, bool) (sql_parse.cc:1834)
 
^ Found warnings in /data/bld/10.4-valgrind/mysql-test/var/log/mysqld.1.err

Plan

 
EXPLAIN EXTENDED SELECT STRAIGHT_JOIN t6.* FROM t1 LEFT JOIN t2 ON t2.b = t1.a LEFT JOIN t3 JOIN t4 ON t3.c = t4.d JOIN t5 ON t4.d = t5.f ON t2.b = t4.e LEFT JOIN t6 ON t6.g = t4.e;
 
id	select_type	table	type	possible_keys	key	key_len	ref	rows	filtered	Extra
 
1	SIMPLE	t1	ALL	NULL	NULL	NULL	NULL	2	100.00	
1	SIMPLE	t2	hash_ALL	NULL	#hash#$hj	1027	test.t1.a	1	100.00	Using where; Using join buffer (flat, BNLH join)
 
1	SIMPLE	t3	ALL	NULL	NULL	NULL	NULL	2	100.00	Using where; Using join buffer (incremental, BNL join)
 
1	SIMPLE	t4	hash_ALL	NULL	#hash#$hj	1032	test.t2.b,test.t3.c	2	100.00	Using where; Using join buffer (incremental, BNLH join)
 
1	SIMPLE	t5	hash_ALL	NULL	#hash#$hj	5	test.t3.c	1	100.00	Using where; Using join buffer (incremental, BNLH join)
 
1	SIMPLE	t6	hash_ALL	NULL	#hash#$hj	1027	test.t4.e	2	100.00	Using where; Using join buffer (incremental, BNLH join)
 
Warnings:
 
Note	1003	select straight_join `test`.`t6`.`g` AS `g` from `test`.`t1` left join `test`.`t2` on(`test`.`t2`.`b` = `test`.`t1`.`a` and `test`.`t1`.`a` is not null) left join (`test`.`t3` join `test`.`t4` join `test`.`t5`) on(`test`.`t4`.`e` = `test`.`t2`.`b` and `test`.`t4`.`d` = `test`.`t3`.`c` and `test`.`t5`.`f` = `test`.`t3`.`c` and `test`.`t2`.`b` is not null and `test`.`t3`.`c` is not null and `test`.`t3`.`c` is not null) left join `test`.`t6` on(`test`.`t6`.`g` = `test`.`t4`.`e` and `test`.`t4`.`e` is not null) where 1

Reproducible on 10.4-10.5.
Couldn't reproduce on 10.3, although maybe I failed to find the right optimizer settings for that.

 Comments   
Comment by Elena Stepanova [ 2021-08-30 ]

A seemingly very simple test case for 10.6+, but of course a lot of logic is just hidden inside sys_schema views.

To be run with --performance-schema=OFF, which is default for the plain server, but MTR enables it).

SET JOIN_BUFFER_SPACE_LIMIT= 16384;
 
SELECT tbl1.* FROM sys.latest_file_io AS tbl1 JOIN sys.schema_table_lock_waits AS tbl2 JOIN INFORMATION_SCHEMA.SQL_FUNCTIONS AS tbl3;

10.6 7271cf48

 
==2723475==ERROR: AddressSanitizer: requested allocation size 0xc00000000000003c (0xc000000000001040 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x10000000000 (thread T5)
 
    #0 0x7fc62162cbc8 in malloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8)
 
    #1 0x55aea542209c in sf_malloc /data/src/10.6/mysys/safemalloc.c:126
 
    #2 0x55aea53ef2ce in my_malloc /data/src/10.6/mysys/my_malloc.c:90
 
    #3 0x55aea3c331af in JOIN_CACHE::alloc_buffer() /data/src/10.6/sql/sql_join_cache.cc:940
 
    #4 0x55aea3c33a06 in JOIN_CACHE::init(bool) /data/src/10.6/sql/sql_join_cache.cc:1073
 
    #5 0x55aea3c41aa1 in JOIN_CACHE_BNL::init(bool) /data/src/10.6/sql/sql_join_cache.cc:3702
 
    #6 0x55aea38b744e in JOIN::init_join_cache_and_keyread() /data/src/10.6/sql/sql_select.cc:29966
 
    #7 0x55aea37edecf in JOIN::optimize_stage2() /data/src/10.6/sql/sql_select.cc:3230
 
    #8 0x55aea37e64af in JOIN::optimize_inner() /data/src/10.6/sql/sql_select.cc:2479
 
    #9 0x55aea37df241 in JOIN::optimize() /data/src/10.6/sql/sql_select.cc:1809
 
    #10 0x55aea380076f in mysql_select(THD*, TABLE_LIST*, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*) /data/src/10.6/sql/sql_select.cc:4979
 
    #11 0x55aea37d0e36 in handle_select(THD*, LEX*, select_result*, unsigned long) /data/src/10.6/sql/sql_select.cc:545
 
    #12 0x55aea3736256 in execute_sqlcom_select /data/src/10.6/sql/sql_parse.cc:6256
 
    #13 0x55aea3724d12 in mysql_execute_command(THD*, bool) /data/src/10.6/sql/sql_parse.cc:3946
 
    #14 0x55aea3741519 in mysql_parse(THD*, char*, unsigned int, Parser_state*) /data/src/10.6/sql/sql_parse.cc:8030
 
    #15 0x55aea37175c7 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool) /data/src/10.6/sql/sql_parse.cc:1896
 
    #16 0x55aea37142eb in do_command(THD*, bool) /data/src/10.6/sql/sql_parse.cc:1404
 
    #17 0x55aea3b7a2fa in do_handle_one_connection(CONNECT*, bool) /data/src/10.6/sql/sql_connect.cc:1418
 
    #18 0x55aea3b79b86 in handle_one_connection /data/src/10.6/sql/sql_connect.cc:1312
 
    #19 0x55aea47e62b6 in pfs_spawn_thread /data/src/10.6/storage/perfschema/pfs.cc:2201
 
    #20 0x7fc620f56608 in start_thread /build/glibc-eX1tMB/glibc-2.31/nptl/pthread_create.c:477
 
 
 
==2723475==HINT: if you don't care about these errors you may set allocator_may_return_null=1
 
SUMMARY: AddressSanitizer: allocation-size-too-big (/lib/x86_64-linux-gnu/libasan.so.5+0x10dbc8) in malloc
 
Thread T5 created by T0 here:
 
    #0 0x7fc621559805 in pthread_create (/lib/x86_64-linux-gnu/libasan.so.5+0x3a805)
 
    #1 0x55aea47e126c in my_thread_create /data/src/10.6/storage/perfschema/my_thread.h:48
 
    #2 0x55aea47e66a9 in pfs_spawn_thread_v1 /data/src/10.6/storage/perfschema/pfs.cc:2252
 
    #3 0x55aea3401cf8 in inline_mysql_thread_create /data/src/10.6/include/mysql/psi/mysql_thread.h:1139
 
    #4 0x55aea34195de in create_thread_to_handle_connection(CONNECT*) /data/src/10.6/sql/mysqld.cc:5922
 
    #5 0x55aea3419c5a in create_new_thread(CONNECT*) /data/src/10.6/sql/mysqld.cc:5981
 
    #6 0x55aea3419fc7 in handle_accepted_socket(st_mysql_socket, st_mysql_socket) /data/src/10.6/sql/mysqld.cc:6043
 
    #7 0x55aea341a9c5 in handle_connections_sockets() /data/src/10.6/sql/mysqld.cc:6167
 
    #8 0x55aea3418dda in mysqld_main(int, char**) /data/src/10.6/sql/mysqld.cc:5817
 
    #9 0x55aea340101c in main /data/src/10.6/sql/main.cc:34
 
    #10 0x7fc620a2e0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
 
 
 
==2723475==ABORTING
 
210830 20:16:33 [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.6.5-MariaDB-debug-log
 
key_buffer_size=1048576
 
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 = 63857 K  bytes of memory
 
Hope that's ok; if not, decrease some variables in the equation.
 
 
 
Thread pointer: 0x62b000070288
 
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 = 0x7fc61ba18cd0 thread_stack 0x100000
 
??:0(__interceptor_tcgetattr)[0x7fc62158bd30]
 
mysys/stacktrace.c:212(my_print_stacktrace)[0x55aea5400d8b]
 
sql/signal_handler.cc:225(handle_fatal_signal)[0x55aea3f7fceb]
 
sigaction.c:0(__restore_rt)[0x7fc620f623c0]
 
??:0(gsignal)[0x7fc620a4d18b]
 
??:0(abort)[0x7fc620a2c859]
 
??:0(__sanitizer_set_report_fd)[0x7fc62164a6a2]
 
??:0(__sanitizer_get_module_and_offset_for_pc)[0x7fc62165524c]
 
??:0(__sanitizer_ptr_cmp)[0x7fc6216368ec]
 
??:0(__asan_on_error)[0x7fc621635866]
 
??:0(__sanitizer_purge_allocator)[0x7fc62154b2ef]
 
??:0(__sanitizer_purge_allocator)[0x7fc62154753b]
 
??:0(malloc)[0x7fc62162cc8f]
 
mysys/safemalloc.c:126(sf_malloc)[0x55aea542209d]
 
mysys/my_malloc.c:90(my_malloc)[0x55aea53ef2cf]
 
sql/sql_join_cache.cc:940(JOIN_CACHE::alloc_buffer())[0x55aea3c331b0]
 
sql/sql_join_cache.cc:1073(JOIN_CACHE::init(bool))[0x55aea3c33a07]
 
sql/sql_join_cache.cc:3702(JOIN_CACHE_BNL::init(bool))[0x55aea3c41aa2]
 
sql/sql_select.cc:29966(JOIN::init_join_cache_and_keyread())[0x55aea38b744f]
 
sql/sql_select.cc:3232(JOIN::optimize_stage2())[0x55aea37eded0]
 
sql/sql_select.cc:2479(JOIN::optimize_inner())[0x55aea37e64b0]
 
sql/sql_select.cc:1809(JOIN::optimize())[0x55aea37df242]
 
sql/sql_select.cc:4979(mysql_select(THD*, TABLE_LIST*, List<Item>&, Item*, unsigned int, st_order*, st_order*, Item*, st_order*, unsigned long long, select_result*, st_select_lex_unit*, st_select_lex*))[0x55aea3800770]
 
sql/sql_select.cc:545(handle_select(THD*, LEX*, select_result*, unsigned long))[0x55aea37d0e37]
 
sql/sql_parse.cc:6256(execute_sqlcom_select(THD*, TABLE_LIST*))[0x55aea3736257]
 
sql/sql_parse.cc:3946(mysql_execute_command(THD*, bool))[0x55aea3724d13]
 
sql/sql_parse.cc:8030(mysql_parse(THD*, char*, unsigned int, Parser_state*))[0x55aea374151a]
 
sql/sql_parse.cc:1898(dispatch_command(enum_server_command, THD*, char*, unsigned int, bool))[0x55aea37175c8]
 
sql/sql_parse.cc:1404(do_command(THD*, bool))[0x55aea37142ec]
 
sql/sql_connect.cc:1418(do_handle_one_connection(CONNECT*, bool))[0x55aea3b7a2fb]
 
sql/sql_connect.cc:1314(handle_one_connection)[0x55aea3b79b87]
 
perfschema/pfs.cc:2203(pfs_spawn_thread)[0x55aea47e62b7]
 
nptl/pthread_create.c:478(start_thread)[0x7fc620f56609]
 
??:0(clone)[0x7fc620b29293]
 
 
 
Trying to get some variables.
 
Some pointers may be invalid and cause the dump to abort.
 
Query (0x62b0000772a8): SELECT tbl1.* FROM sys.latest_file_io AS tbl1 JOIN sys.schema_table_lock_waits AS tbl2 JOIN INFORMATION_SCHEMA.SQL_FUNCTIONS AS tbl3
 
 
 
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 https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
 
information that should help you find out what is causing the crash.
 
Writing a core file...
 
Working directory at /dev/shm/var_auto_mbIN/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        unlimited            unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             385737               385737               processes 
Max open files            1024                 1024                 files     
Max locked memory         67108864             67108864             bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       385737               385737               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: |/usr/share/apport/apport %p %s %c %d %P %E

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