Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL), 10.10(EOL), 10.11, 11.0(EOL), 11.1(EOL)
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.
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
-
- Closed
-
Activity
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).
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.
Also repeatable with direct execution (instead of EXECUTE IMMEDIATE):
DELIMITER $$;
|
--error ER_PARSE_ERROR
|
BEGIN NOT ATOMIC |
IF(SCALAR()) expected_THEN_here; |
END
|
$$
|
DELIMITER ;$$
|
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 ;$$
|
Hi dshulga, can you please review a patch:
https://github.com/MariaDB/server/commit/cb334ae07f5286198b9d5d15eb4f908cac5af7fc
Thanks!
shulga Could you have a look at the patch please? We see this error somewhat regularly in testing. Thank you!
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
|
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.
The new patch is here:
https://github.com/MariaDB/server/commit/575ab6d3fd8d2d311d55391d54f3f665c3ae07ac
Additional testcase now gives LeakSanitizer: detected memory leaks, likely from sp_add_used_routine. Again has to be reproduced in CLI.
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 completeWarning: Memory not freed: 280===================================================================2471466==ERROR: LeakSanitizer: detected memory leaksDirect 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:442SUMMARY: AddressSanitizer: 280 byte(s) leaked in 1 allocation(s).230513 14:01:56 [ERROR] mysqld got signal 6 ;