[MDEV-24900] "select 'a' 'b';" causes a leak. Created: 2021-02-17  Updated: 2021-02-18  Resolved: 2021-02-17

Status: Closed
Project: MariaDB Server
Component/s: Server
Affects Version/s: 10.4.17
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Johan Wikman Assignee: Sergei Golubchik
Resolution: Cannot Reproduce Votes: 0
Labels: None
Environment:

Ubuntu 18.04


 Description   

I'm using the embedded library. Parsing the statement

select 'a' 'b';

causes the following report by ASAN.

Direct leak of 144 byte(s) in 1 object(s) allocated from:
 
    #0 0x7f4948212b40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
 
    #1 0x7f493e652f16 in my_malloc /home/buildbot/buildbot/build/mysys/my_malloc.c:101
 
    #2 0x7f493eb92c5f in Binary_string::realloc_raw(unsigned long) /home/buildbot/buildbot/build/sql/sql_string.cc:101
 
    #3 0x7f493eb93760 in Binary_string::realloc_with_extra(unsigned long) /home/buildbot/buildbot/build/sql/sql_string.h:634
 
    #4 0x7f493eb93760 in Binary_string::realloc_with_extra_if_needed(unsigned long) /home/buildbot/buildbot/build/sql/sql_string.h:646
 
    #5 0x7f493eb93760 in Binary_string::append(char const*, unsigned long) /home/buildbot/buildbot/build/sql/sql_string.h:535
 
    #6 0x7f493eb93760 in String::append(char const*, unsigned long) /home/buildbot/buildbot/build/sql/sql_string.cc:547
 
    #7 0x7f493e770335 in Item_string::append(char const*, unsigned int) /home/buildbot/buildbot/build/sql/item.h:4444
 
    #8 0x7f493e770335 in Item_string::make_string_literal_concat(THD*, st_mysql_const_lex_string const*) /home/buildbot/buildbot/build/sql/item.cc:6624
 
    #9 0x7f493eb57029 in MYSQLparse(THD*) /home/buildbot/buildbot/build/sql/sql_yacc.yy:15274
 
    #10 0x7f493e6604c4 in parse_sql(THD*, Parser_state*, Object_creation_ctx*, bool) /home/buildbot/buildbot/build/sql/sql_parse.cc:10295
 
...



 Comments   
Comment by Sergei Golubchik [ 2021-02-17 ]

I cannot repeat it, the memory is freed at

#1  0x0000555555c2f599 in Binary_string::free (this=0x555557cc8218)
 
    at libmysqld/../sql/sql_string.h:610
 
#2  0x0000555555c2f502 in Binary_string::~Binary_string (this=0x555557cc8218, 
    __in_chrg=<optimized out>) at libmysqld/../sql/sql_string.h:420
 
#3  0x0000555555c2f728 in String::~String (
 
    this=(String * const) 0x555557cc8210 _latin1_swedish_ci "ab", 
    __in_chrg=<optimized out>) at libmysqld/../sql/sql_string.h:728
 
#4  0x0000555555c6e1b8 in Item::~Item (this=0x555557cc81e0, 
    __in_chrg=<optimized out>) at sql/item.h:944
 
#5  0x0000555555c6fbb3 in Item_basic_value::~Item_basic_value (
 
    this=0x555557cc81e0, __in_chrg=<optimized out>) at sql/item.h:2740
 
#6  0x0000555555c6fd03 in Item_basic_constant::~Item_basic_constant (
 
    this=0x555557cc81e0, __in_chrg=<optimized out>) at sql/item.h:2801
 
#7  0x0000555555c6fe17 in Item_literal::~Item_literal (this=0x555557cc81e0, 
    __in_chrg=<optimized out>) at sql/item.h:3190
 
#8  0x0000555555c70463 in Item_string::~Item_string (this=0x555557cc81e0, 
    __in_chrg=<optimized out>) at sql/item.h:4347
 
#9  0x0000555555c70484 in Item_string::~Item_string (this=0x555557cc81e0, 
    __in_chrg=<optimized out>) at sql/item.h:4347
 
#10 0x0000555555d2e7e7 in Item::delete_self (this=0x555557cc81e0)
 
    at sql/item.h:2220
 
#11 0x0000555555d2485b in Query_arena::free_items (this=0x555557c66478)
 
    at sql/sql_class.cc:3787
 
#12 0x0000555555d1f4a7 in THD::cleanup_after_query (this=0x555557c66460)
 
    at sql/sql_class.cc:2288
 
#13 0x0000555555da5cb9 in mysql_parse (thd=0x555557c66460, 
    rawbuf=0x555557cc7cf8 "select 'a' 'b'", length=14, 
    parser_state=0x7ffff61d44f0, is_com_multi=false, is_next_command=false)
 
    at sql/sql_parse.cc:7985
 
#14 0x0000555555d98ea9 in dispatch_command (command=COM_QUERY, 
    thd=0x555557c66460, packet=0x555557c845f0 "select 'a' 'b'", 
    packet_length=14, is_com_multi=false, is_next_command=false)
 
    at sql/sql_parse.cc:1857
 
#15 0x0000555555c2b3f1 in emb_advanced_command (mysql=0x555557b3aff0, 
    command=COM_QUERY, header=0x0, header_length=0, 
    arg=0x555557c845f0 "select 'a' 'b'", arg_length=14, skip_check=1 '\001', 
    stmt=0x0) at libmysqld/lib_sql.cc:171
 
#16 0x0000555555c1f699 in mysql_send_query (mysql=0x555557b3aff0, 
    query=0x555557c845f0 "select 'a' 'b'", length=14)
 
    at sql-common/client.c:3584
 
#17 0x0000555555bc912b in connection_thread (arg=0x555557b4df30)
 
    at client/mysqltest.cc:918

Comment by Johan Wikman [ 2021-02-17 ]

It appears that there was no call to THD:::cleanup_after_query before the thd was destroyed. When that was added, ASAN stopped complaining.

Strangely, although we parse thousands of statements from the server test-suite, when comparing that the sqlite-based classifier classifies a statement the same way as the libmysqlembedded one does, this was the only case where the missing cleanup_after_query call caused a leak.

Comment by Sergei Golubchik [ 2021-02-17 ]

Here it is in 10.4.17: https://github.com/MariaDB/server/blob/mariadb-10.4.17/sql/sql_parse.cc#L7962

Comment by Johan Wikman [ 2021-02-18 ]

Yes, I phrased myself poorly. Ours is very old code and for whatever reason that mysql_parse() function is not used as such, but instead a homegrown rough equivalent. And there was no call to cleanup_after_query in that. The fact that ASAN complained about just 1 out of thousands of statements led me astray. Sorry for the confusion.

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