Re: (ITS#9155) LMDB: List of spill pages leaks after transaction

babayants.alexander@gmail.com wrote:

Full_Name: Alexander Babayants Version: LMDB 0.9.24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.170.78.53)

Hi!

ASAN shows that the list of spill pages is not freed after transaction:

Thanks for the report. Fixed now in mdb.master and mdb.RE/0.9

================================================================= ==test==13046==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 20971376 byte(s) in 1 object(s) allocated from: #0 0x4bcbb2 in realloc (test+0x4bcbb2) #1 0x7f067ef5ed59 in mdb_midl_grow liblmdb/src/midl.c:135:8 #2 0x7f067ef5ec83 in mdb_midl_append liblmdb/src/midl.c:162:7 #3 0x7f067ef4456b in mdb_page_spill liblmdb/src/mdb.c:2077:13 #4 0x7f067ef3960b in mdb_cursor_put liblmdb/src/mdb.c:6640:14 #5 0x7f067ef5106c in mdb_put liblmdb/src/mdb.c:9027:7 #6 0x4ec674 in main test.c:28:14 #7 0x7f067b46d544 in __libc_start_main (/lib64/libc.so.6+0x22544)

SUMMARY: AddressSanitizer: 20971376 byte(s) leaked in 1 allocation(s).

Reproducible on LMDB 0.9.24 with the following code (anything doing long write transaction will trigger this): #include "lmdb.h"

int main(int argc,char * argv[]) { int rc; MDB_env *env; MDB_dbi dbi; MDB_val key, data; MDB_txn *txn; int kval; char sval[1024] = {0}; // fine to fill with zeroes

rc = mdb_env_create(&env);
rc = mdb_env_set_mapsize(env, 10ULL * 1024 * 1024 * 1024); // 10 GiB
rc = mdb_env_open(env, "./testdb", 0, 0664);
rc = mdb_txn_begin(env, NULL, 0, &txn);
rc = mdb_dbi_open(txn, NULL, 0, &dbi);

key.mv_size = sizeof(int);
key.mv_data = &kval;
data.mv_size = sizeof(sval);
data.mv_data = sval;

for (kval = 0; kval < 100'000'000; ++kval) {
    rc = mdb_put(txn, dbi, &key, &data, 0);
}
rc = mdb_txn_commit(txn);

mdb_dbi_close(env, dbi);
mdb_env_close(env);
return 0;

}

...

From my point of view the leak looks benign (=does not lead to

database corruption or such), but I didn't dive deep enough in LMDB internals to be completely certain about that.

Regards, Alexander Babayants.