[MDEV-22034] leaks in slave_connection_state::slave_connection_state() and Domain_id_filter::Domain_id_filter() Created: 2020-03-25  Updated: 2022-09-22

Status: Open
Project: MariaDB Server
Component/s: Replication
Affects Version/s: 10.5
Fix Version/s: 10.5

Type: Bug Priority: Major
Reporter: Andrei Elkin Assignee: Andrei Elkin
Resolution: Unresolved Votes: 0
Labels: None


 Description   

At MDEV-22031 analysis the following stacks were found 

Version: '10.5.2-MariaDB-debug'  socket: '/tmp/mysql.sock'  port: 3306  Source distribution
 
2020-03-25  7:20:28 0 [Note] sql/mysqld (initiated by: unknown): Normal shutdown
 
2020-03-25  7:20:28 0 [Note] InnoDB: FTS optimize thread exiting.
 
2020-03-25  7:20:28 0 [Note] InnoDB: Starting shutdown...
 
2020-03-25  7:20:28 0 [Note] InnoDB: Dumping buffer pool(s) to /dev/shm/data/ib_buffer_pool
 
2020-03-25  7:20:28 0 [Note] InnoDB: Buffer pool(s) dump completed at 200325  7:20:28
 
2020-03-25  7:20:31 0 [Note] InnoDB: Shutdown completed; log sequence number 18288986; transaction id 43442
 
2020-03-25  7:20:31 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
 
2020-03-25  7:20:31 0 [Note] sql/mysqld: Shutdown complete
 
=================================================================
 
==27012==ERROR: LeakSanitizer: detected memory leaks
 
Direct leak of 21888 byte(s) in 1 object(s) allocated from:
 
    #0 0x7c202d in operator new(unsigned long) (/dev/shm/10.5a/sql/mariadbd+0x7c202d)
 
    #1 0x828f2d in init_slave() /mariadb/10.5m/sql/slave.cc:739:20
 
    #2 0x7ce347 in mysqld_main(int, char**) /mariadb/10.5m/sql/mysqld.cc:5710:7
 
    #3 0x7fa0dc0c3e0a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x26e0a)
 
Indirect leak of 1608 byte(s) in 3 object(s) allocated from:
 
    #0 0x7928bd in malloc (/dev/shm/10.5a/sql/mariadbd+0x7928bd)
 
    #1 0x287ff7c in my_malloc /mariadb/10.5m/mysys/my_malloc.c:88:29
 
    #2 0x27df7e0 in init_dynamic_array2 /mariadb/10.5m/mysys/array.c:71:33
 
    #3 0x27f085b in my_hash_init2 /mariadb/10.5m/mysys/hash.c:98:8
 
    #4 0xfc31b9 in slave_connection_state::slave_connection_state() /mariadb/10.5m/sql/rpl_gtid.cc:2244:3
 
    #5 0xe8b18a in Master_info::Master_info(st_mysql_const_lex_string*, bool) /mariadb/10.5m/sql/rpl_mi.cc:35:4
 
Indirect leak of 536 byte(s) in 1 object(s) allocated from:
 
    #0 0x7928bd in malloc (/dev/shm/10.5a/sql/mariadbd+0x7928bd)
 
    #1 0x287ff7c in my_malloc /mariadb/10.5m/mysys/my_malloc.c:88:29
 
    #2 0x27df7e0 in init_dynamic_array2 /mariadb/10.5m/mysys/array.c:71:33
 
    #3 0x27f085b in my_hash_init2 /mariadb/10.5m/mysys/hash.c:98:8
 
    #4 0xfd95dd in rpl_parallel::rpl_parallel() /mariadb/10.5m/sql/rpl_parallel.cc:2215:3
 
    #5 0xe8b18a in Master_info::Master_info(st_mysql_const_lex_string*, bool) /mariadb/10.5m/sql/rpl_mi.cc:35:4
 
Indirect leak of 536 byte(s) in 1 object(s) allocated from:
 
    #0 0x7928bd in malloc (/dev/shm/10.5a/sql/mariadbd+0x7928bd)
 
    #1 0x287ff7c in my_malloc /mariadb/10.5m/mysys/my_malloc.c:88:29
 
    #2 0x27df7e0 in init_dynamic_array2 /mariadb/10.5m/mysys/array.c:71:33
 
    #3 0x27f085b in my_hash_init2 /mariadb/10.5m/mysys/hash.c:98:8
 
    #4 0xfbda0b in rpl_binlog_state::init() /mariadb/10.5m/sql/rpl_gtid.cc:1480:3
 
    #5 0xe8b18a in Master_info::Master_info(st_mysql_const_lex_string*, bool) /mariadb/10.5m/sql/rpl_mi.cc:35:4
 
Indirect leak of 536 byte(s) in 1 object(s) allocated from:
 
    #0 0x7928bd in malloc (/dev/shm/10.5a/sql/mariadbd+0x7928bd)
 
    #1 0x287ff7c in my_malloc /mariadb/10.5m/mysys/my_malloc.c:88:29
 
    #2 0x27df7e0 in init_dynamic_array2 /mariadb/10.5m/mysys/array.c:71:33
 
    #3 0x27f085b in my_hash_init2 /mariadb/10.5m/mysys/hash.c:98:8
 
    #4 0xfc31b9 in slave_connection_state::slave_connection_state() /mariadb/10.5m/sql/rpl_gtid.cc:2244:3
 
Indirect leak of 456 byte(s) in 3 object(s) allocated from:
 
    #0 0x7928bd in malloc (/dev/shm/10.5a/sql/mariadbd+0x7928bd)
 
    #1 0x287ff7c in my_malloc /mariadb/10.5m/mysys/my_malloc.c:88:29
 
    #2 0x27df7e0 in init_dynamic_array2 /mariadb/10.5m/mysys/array.c:71:33
 
    #3 0xfc31e2 in slave_connection_state::slave_connection_state() /mariadb/10.5m/sql/rpl_gtid.cc:2247:3
 
    #4 0xe8b18a in Master_info::Master_info(st_mysql_const_lex_string*, bool) /mariadb/10.5m/sql/rpl_mi.cc:35:4
 
Indirect leak of 152 byte(s) in 1 object(s) allocated from:
 
    #0 0x7928bd in malloc (/dev/shm/10.5a/sql/mariadbd+0x7928bd)
 
    #1 0x287ff7c in my_malloc /mariadb/10.5m/mysys/my_malloc.c:88:29
 
    #2 0x27df7e0 in init_dynamic_array2 /mariadb/10.5m/mysys/array.c:71:33
 
    #3 0xe8b86f in Master_info::Master_info(st_mysql_const_lex_string*, bool) /mariadb/10.5m/sql/rpl_mi.cc:80:3
 
Indirect leak of 152 byte(s) in 1 object(s) allocated from:
 
    #0 0x7928bd in malloc (/dev/shm/10.5a/sql/mariadbd+0x7928bd)
 
    #1 0x287ff7c in my_malloc /mariadb/10.5m/mysys/my_malloc.c:88:29
 
    #2 0x27df7e0 in init_dynamic_array2 /mariadb/10.5m/mysys/array.c:71:33
 
    #3 0xe8b462 in Domain_id_filter::Domain_id_filter() /mariadb/10.5m/sql/rpl_mi.cc:1745:5
 
    #4 0xe8b462 in Master_info::Master_info(st_mysql_const_lex_string*, bool) /mariadb/10.5m/sql/rpl_mi.cc:31:14
 
Indirect leak of 152 byte(s) in 1 object(s) allocated from:
 
    #0 0x7928bd in malloc (/dev/shm/10.5a/sql/mariadbd+0x7928bd)
 
    #1 0x287ff7c in my_malloc /mariadb/10.5m/mysys/my_malloc.c:88:29
 
    #2 0x27df7e0 in init_dynamic_array2 /mariadb/10.5m/mysys/array.c:71:33
 
    #3 0xfbda37 in rpl_binlog_state::init() /mariadb/10.5m/sql/rpl_gtid.cc:1482:3
 
    #4 0xe8b18a in Master_info::Master_info(st_mysql_const_lex_string*, bool) /mariadb/10.5m/sql/rpl_mi.cc:35:4
 
Indirect leak of 152 byte(s) in 1 object(s) allocated from:
 
    #0 0x7928bd in malloc (/dev/shm/10.5a/sql/mariadbd+0x7928bd)
 
    #1 0x287ff7c in my_malloc /mariadb/10.5m/mysys/my_malloc.c:88:29
 
    #2 0x27df7e0 in init_dynamic_array2 /mariadb/10.5m/mysys/array.c:71:33
 
    #3 0xe8b436 in Domain_id_filter::Domain_id_filter() /mariadb/10.5m/sql/rpl_mi.cc:1745:5
 
    #4 0xe8b436 in Master_info::Master_info(st_mysql_const_lex_string*, bool) /mariadb/10.5m/sql/rpl_mi.cc:31:14
 
Indirect leak of 152 byte(s) in 1 object(s) allocated from:
 
    #0 0x7928bd in malloc (/dev/shm/10.5a/sql/mariadbd+0x7928bd)
 
    #1 0x287ff7c in my_malloc /mariadb/10.5m/mysys/my_malloc.c:88:29
 
    #2 0x27df7e0 in init_dynamic_array2 /mariadb/10.5m/mysys/array.c:71:33
 
    #3 0xfc31e2 in slave_connection_state::slave_connection_state() /mariadb/10.5m/sql/rpl_gtid.cc:2247:3
 
Indirect leak of 32 byte(s) in 1 object(s) allocated from:
 
    #0 0x7928bd in malloc (/dev/shm/10.5a/sql/mariadbd+0x7928bd)
 
    #1 0x287ff7c in my_malloc /mariadb/10.5m/mysys/my_malloc.c:88:29
 
    #2 0xe8b647 in Master_info::Master_info(st_mysql_const_lex_string*, bool) /mariadb/10.5m/sql/rpl_mi.cc:61:8
 
SUMMARY: AddressSanitizer: 26352 byte(s) leaked in 16 allocation(s).



 Comments   
Comment by Marko Mäkelä [ 2020-03-25 ]

I repeated it on a cmake -DWITH_ASAN=ON -DCMAKE_BUILD_TYPE=Debug build of 10.5 19e998d20c2b209305057fddb8fddf243d4f0619:

tar xzf data-10.1.44.tar.gz -C /dev/shm data
 
sql/mysqld --datadir /dev/shm/data --innodb-page-size=4K --innodb-compression-algorithm=none --skip-innodb-fast-shutdown

It only repeats for about half the runs. I had to disable a debug assertion that would catch the leak before ASAN:

diff --git a/sql/mysqld.cc b/sql/mysqld.cc
 
index 7cf85b72d71..256770bf90e 100644
 
--- a/sql/mysqld.cc
 
+++ b/sql/mysqld.cc
 
@@ -1947,7 +1947,7 @@ static void mysqld_exit(int exit_code)
 
 #ifdef SAFEMALLOC
 
     sf_report_leaked_memory(0);
 
 #endif
 
-    DBUG_SLOW_ASSERT(global_status_var.global_memory_used == 0);
 
+//  DBUG_SLOW_ASSERT(global_status_var.global_memory_used == 0);
 
   }
 
   cleanup_tls();
 
   DBUG_LEAVE;

Comment by Andrei Elkin [ 2020-06-12 ]

Can't be fixed right now.

It could not be reproduced as sujatha.sivakumar reports. By labeling with need_feedback I am requesting more data, and the best - how to reproduce.

Comment by Andrei Elkin [ 2020-07-14 ]

elenst: By anybody, myself included. Maybe marko is the best to provide (thanks for inferring to inform him!). The labeling meant to explain why we can't proceed with it. Let me restore it.

Comment by Elena Stepanova [ 2020-07-14 ]

Elkin,

> The labeling meant to explain why we can't proceed with it. Let me restore it.
In this case the label means nothing other than the issue is allowed to be ignored for the next month.
If you need information from marko, I suggest assigning it to Marko. If you request information from yourself, I hope you can do without the label (you can invent your own one, if you need it).
If the JIRA cannot be proceeded with at all, then close it as incomplete, or won't fix, or whatever fits.

Comment by Andrei Elkin [ 2020-07-14 ]

elenst: Developers, not just myself, do need in my experience a bug state that reads OPEN and CANT-REPRODUCE. I spotted
need_feedback is exactly about that. But I sure could not know you and somebody attached to the label some
sacred meaning.
It does not mean who would provide more details. The thing is to say we know it's an issue, so we can't close it.
But it's not feasible to tackle it due to lack of info.

After I've explained more, are you still certain need_feedback is bad for this purpose?

Comment by Andrei Elkin [ 2020-07-14 ]

elenst It makes sense what you're saying (as usual). In the current case, the feedback provider could be only Marko, and I failed to make him the provider.

Let me now (after I've looked into it for the last time, just in case) follow the protocol and request it the re-assign way. And in case it won't be provided, it may be closed through your deliberation.

The label then would serve to my purpose to indicate OPEN && CANT-YET-REPRODUCE for at least one month, as you explain.

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