[MDEV-30680] Warning: Memory not freed: 280 on mangled query, LeakSanitizer: detected memory leaks Created: 2023-02-18  Updated: 2023-07-18  Resolved: 2023-06-29

Status: Closed
Project: MariaDB Server
Component/s: Stored routines
Affects Version/s: 10.5, 10.6, 10.7, 10.8, 10.9, 10.10, 10.11, 11.0, 11.1
Fix Version/s: 10.8.8, 10.5.22, 10.6.15, 10.9.8, 10.10.6, 10.11.5, 11.0.3, 11.1.2

Type: Bug Priority: Major
Reporter: Roel Van de Paar Assignee: Alexander Barkov
Resolution: Fixed Votes: 0
Labels: LSAN, Memory_leak, regression-10.5

Issue Links:
Relates
relates to MDEV-26186 280 Bytes lost in mysys/array.c, mysy... Closed
relates to MDEV-31578 DECLARE CURSOR: "Memory not freed: 28... Closed

 Description   

Present in 10.5+ only, both in debug and optimized.

IF(NOT (scalar (@0s)>scalar (@0s))) { die (.);�ku u va�oj SQL sINTaksi{ die (. na liniji0;;
 
SHUTDOWN;

Leads to (ref error log after shutdown):

11.0.1 f2dc4d4c10ac36a73b5c1eb765352d3aee808d66 (Debug)

 
2023-02-18 14:22:07 0 [Note] /test/MD180223-mariadb-11.0.1-linux-x86_64-dbg/bin/mariadbd: Shutdown complete
 
Warning: Memory not freed: 280

In all affected versions.

No UBSAN/ASAN issues observed.

I tried to make this work under MTR for some time, but failed. AFAICS ftm, this issue can only be reproduced in a client, not in MTR, not even when using the CLI via MTR i.e. --start-and-exit.

As such, you will need to start mariadbd and then mariadb manually/directly to reproduce.

 Comments   
Comment by Roel Van de Paar [ 2023-05-13 ]

Additional testcase now gives LeakSanitizer: detected memory leaks, likely from sp_add_used_routine. Again has to be reproduced in CLI.

IF(SCALAR(@0s)=0){s();
 
SHUTDOWN;

Leads to:

11.0.2 368dd22a816f3b437bccd0b9ff28b9de9b1abf0a (Debug)

 
2023-05-13 14:01:55 0 [Note] /test/UBASAN_MD120523-mariadb-11.0.2-linux-x86_64-dbg/bin/mariadbd: Shutdown complete
 
 
 
Warning: Memory not freed: 280
 
 
 
=================================================================
 
==2471466==ERROR: LeakSanitizer: detected memory leaks
 
 
 
Direct leak of 280 byte(s) in 1 object(s) allocated from:
 
    #0 0x5637a4d68337 in __interceptor_malloc (/test/UBASAN_MD120523-mariadb-11.0.2-linux-x86_64-dbg/bin/mariadbd+0x7964337)
 
    #1 0x5637a947f703 in my_malloc /test/11.0_dbg_san/mysys/my_malloc.c:91
 
    #2 0x5637a941352b in init_dynamic_array2 /test/11.0_dbg_san/mysys/array.c:73
 
    #3 0x5637a9423c9d in my_hash_init2 /test/11.0_dbg_san/mysys/hash.c:99
 
    #4 0x5637a7d6b865 in sp_add_used_routine(Query_tables_list*, Query_arena*, MDL_key const*, Sp_handler const*, TABLE_LIST*) /test/11.0_dbg_san/sql/sp.cc:2328
 
    #5 0x5637a7d6fd55 in Sp_handler::add_used_routine(Query_tables_list*, Query_arena*, Database_qualified_name const*) const /test/11.0_dbg_san/sql/sp.cc:2642
 
    #6 0x5637a728717f in Create_sp_func::create_with_db(THD*, st_mysql_const_lex_string const*, st_mysql_const_lex_string const*, bool, List<Item>*) /test/11.0_dbg_san/sql/item_create.cc:2731
 
    #7 0x5637a722912d in Create_qfunc::create_func(THD*, st_mysql_const_lex_string const*, List<Item>*) /test/11.0_dbg_san/sql/item_create.cc:2578
 
    #8 0x5637a69279f3 in MYSQLparse(THD*) /test/11.0_dbg_san/sql/sql_yacc.yy:10516
 
    #9 0x5637a56e1383 in parse_sql(THD*, Parser_state*, Object_creation_ctx*, bool) /test/11.0_dbg_san/sql/sql_parse.cc:10409
 
    #10 0x5637a56e2f31 in mysql_parse(THD*, char*, unsigned int, Parser_state*) /test/11.0_dbg_san/sql/sql_parse.cc:7966
 
    #11 0x5637a56f3707 in dispatch_command(enum_server_command, THD*, char*, unsigned int, bool) /test/11.0_dbg_san/sql/sql_parse.cc:1894
 
    #12 0x5637a5701542 in do_command(THD*, bool) /test/11.0_dbg_san/sql/sql_parse.cc:1407
 
    #13 0x5637a60d68b5 in do_handle_one_connection(CONNECT*, bool) /test/11.0_dbg_san/sql/sql_connect.cc:1416
 
    #14 0x5637a60d7dd0 in handle_one_connection /test/11.0_dbg_san/sql/sql_connect.cc:1318
 
    #15 0x148133a94b42 in start_thread nptl/pthread_create.c:442
 
 
 
SUMMARY: AddressSanitizer: 280 byte(s) leaked in 1 allocation(s).
 
230513 14:01:56 [ERROR] mysqld got signal 6 ;

Comment by Alexander Barkov [ 2023-05-15 ]

Can be reproduced using this MTR test:

--error ER_PARSE_ERROR
 
EXECUTE IMMEDIATE 'IF(SCALAR(@0s)=0){s()';

The output is:

worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
 
EXECUTE IMMEDIATE 'IF(SCALAR(@0s)=0){s()';
 
ERROR 42000: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '{s()' at line 1
 
main.AAA                                 [ pass ]       
***Warnings generated in error logs during shutdown after running tests: main.AAA
 
 
 
Warning: Memory not freed: 280
 
Warning:  280 bytes lost at 0x7fd95c00ab90, allocated by T@0 at mysys/array.c:72, mysys/hash.c:99, sql/sp.cc:2331, sql/sp.cc:2646, sql/item_create.cc:2631, sql/item_create.cc:2477, sql/sql_yacc.yy:10750, sql/sql_parse.cc:10498
 
Warning:  280 bytes lost at 0x7fd95c00ab90, allocated by T@0 at mysys/array.c:72, mysys/hash.c:99, sql/sp.cc:2331, sql/sp.cc:2646, sql/item_create.cc:2631, sql/item_create.cc:2477, sql/sql_yacc.yy:10750, sql/sql_parse.cc:10498

Note, warnings are reproducible even with a simple -DCMAKE_BUILD_TYPE=Debug build (-DWITH_UBSAN=1 is not needed).

Comment by Roel Van de Paar [ 2023-05-15 ]

bar Nice, thank you!

Yes, -DWITH_ASAN=1 (LSAN is part of ASAN) is not needed, however when used it provides the full relevant stack trace.

Comment by Alexander Barkov [ 2023-05-15 ]

Also repeatable with direct execution (instead of EXECUTE IMMEDIATE):

DELIMITER $$;
 
--error ER_PARSE_ERROR
 
BEGIN NOT ATOMIC
 
  IF(SCALAR()) expected_THEN_here;
 
END
 
$$
 
DELIMITER ;$$

Comment by Alexander Barkov [ 2023-05-15 ]

The problem is also repeatable with the following scripts:

DELIMITER $$;
 
--error ER_PARSE_ERROR
 
BEGIN NOT ATOMIC
 
  WHILE SCALAR() expected_DO_here;
 
END
 
$$
 
DELIMITER ;$$


DELIMITER $$;
 
--error ER_PARSE_ERROR
 
BEGIN NOT ATOMIC
 
  REPEAT SELECT 1; UNTIL SCALAR() expected_END_here;
 
END
 
$$
 
DELIMITER ;$$

Comment by Alexander Barkov [ 2023-05-15 ]

Hi dshulga, can you please review a patch:

https://github.com/MariaDB/server/commit/cb334ae07f5286198b9d5d15eb4f908cac5af7fc

Thanks!

Comment by Roel Van de Paar [ 2023-06-08 ]

shulga Could you have a look at the patch please? We see this error somewhat regularly in testing. Thank you!

Comment by Roel Van de Paar [ 2023-06-14 ]

Please also test

IF(NOT (SCALAR (@0s)>SCALAR (@0s))) { die (.);
 
SHUTDOWN;

Against LSAN.

LSAN|memory leak|mysys/my_malloc.c|malloc|my_malloc|init_dynamic_array2|sp_add_used_routine

Comment by Dmitry Shulga [ 2023-06-20 ]

The patch approved

Comment by Alexander Barkov [ 2023-06-22 ]

The problem is also repeatable with:

DELIMITER $$
 
BEGIN NOT ATOMIC
 
  DECLARE cur CURSOR (a INT) FOR SELECT a+1;
 
  OPEN cur(sp_followed_by_syntax_error();
 
  CLOSE cur;
 
END;
 
$$
 
DELIMITER ;

It's now reported as a separate issue MDEV-31578.

Comment by Alexander Barkov [ 2023-06-22 ]

The new patch is here:

https://github.com/MariaDB/server/commit/575ab6d3fd8d2d311d55391d54f3f665c3ae07ac

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