If run with an ASAN build the following test fails:
suites/attr_encryption/attr_encryption_test.py::test_export_import_plaintext
It looks like an offline db2ldif returns an error raised by asan and the test fails. Running just the db2ldif:
<inst>/ns-slapd db2ldif -D <inst>/etc/dirsrv/slapd-standalone1 -n userRoot -s dc=example,dc=com -E -a <inst>/var/lib/dirsrv/slapd-standalone1/ldif/export_plaintext.ldif
we get this report:
================================================================= ==30315==ERROR: LeakSanitizer: detected memory leaks Direct leak of 7181 byte(s) in 3 object(s) allocated from: #0 0x7f810a1ee008 in malloc (/lib64/libasan.so.5+0xef008) #1 0x7f81079013b1 in PORT_Alloc_Util (/lib64/libnssutil3.so+0x173b1) Direct leak of 336 byte(s) in 2 object(s) allocated from: #0 0x7f810a1ee210 in calloc (/lib64/libasan.so.5+0xef210) #1 0x7f81072c5340 in PR_NewLock ../../.././nspr/pr/src/pthreads/ptsynch.c:136 #2 0x7f80fb3750c5 in attrcrypt_init /home/lkrispen/TEST/caa/ws/389-ds-base/ldap/servers/slapd/back-ldbm/ldbm_attrcrypt.c:537 #3 0x7f80fb2d57b0 in dblayer_instance_start /home/lkrispen/TEST/caa/ws/389-ds-base/ldap/servers/slapd/back-ldbm/dblayer.c:1739 #4 0x7f80fb3e4af5 in ldbm_back_ldbm2ldif /home/lkrispen/TEST/caa/ws/389-ds-base/ldap/servers/slapd/back-ldbm/ldif2ldbm.c:1340 #5 0x453228 in slapd_exemode_db2ldif /home/lkrispen/TEST/caa/ws/389-ds-base/ldap/servers/slapd/main.c:2372 #6 0x447ba9 in main /home/lkrispen/TEST/caa/ws/389-ds-base/ldap/servers/slapd/main.c:970 #7 0x7f810645711a in __libc_start_main (/lib64/libc.so.6+0x2311a) Indirect leak of 12671 byte(s) in 6 object(s) allocated from: #0 0x7f810a1ee008 in malloc (/lib64/libasan.so.5+0xef008) #1 0x7f81076e70b6 in PL_ArenaAllocate ../.././nspr/lib/ds/plarena.c:127 Indirect leak of 672 byte(s) in 4 object(s) allocated from: #0 0x7f810a1ee210 in calloc (/lib64/libasan.so.5+0xef210) #1 0x7f81072c5340 in PR_NewLock ../../.././nspr/pr/src/pthreads/ptsynch.c:136 Indirect leak of 288 byte(s) in 4 object(s) allocated from: #0 0x7f810a1ee210 in calloc (/lib64/libasan.so.5+0xef210) #1 0x7f8107901498 in PORT_ZAlloc_Util (/lib64/libnssutil3.so+0x17498) SUMMARY: AddressSanitizer: 21148 byte(s) leaked in 19 allocation(s).
The leak in attrcrypt_init() can be fixed by this change:
diff --git a/ldap/servers/slapd/back-ldbm/ldbm_attrcrypt.c b/ldap/servers/slapd/back-ldbm/ldbm_attrcrypt.c index 19ee67e65..cdf337bd7 100644 --- a/ldap/servers/slapd/back-ldbm/ldbm_attrcrypt.c +++ b/ldap/servers/slapd/back-ldbm/ldbm_attrcrypt.c @@ -605,6 +605,9 @@ attrcrypt_cleanup(attrcrypt_cipher_state *acs) if (acs->slot) { slapd_pk11_FreeSlot(acs->slot); } + if (acs->cipher_lock) { + PR_DestroyLock(acs->cipher_lock); + } slapi_log_err(SLAPI_LOG_TRACE, "attrcrypt_cleanup", "<-\n"); return 0; }
but the others remain and I have no idea how to find what causes it in our code or if it is a leak in nspr/nss
I did build nss and nspr with ASAN and preloaded it for the db2ldif, now we get full callstacks :-)
<img alt="asan.out" src="/389-ds-base/issue/raw/files/7d792a702ccef9bc18db45df6637b523b5218299eaef2313d8c918f865f0234d-asan.out" />
Metadata Update from @lkrispen: - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None
just for the record, the steps to produce and use the asan builds:
1] install gyp and ninja-build 2] get the sources
hg clone https://hg.mozilla.org/projects/nspr hg clone https://hg.mozilla.org/projects/nss
3] build it:
nss/build.sh -c --asan --disable-tests
4] check for the libs they are in:
dist/Debug/lib
5] preload asan and nss/nspr libs
LD_PRELOAD="/usr/lib64/libasan.so.5" for so in `ls <comp build dir>/nss/dist/Debug/lib/*.so do LD_PRELOAD=$LD_PRELOAD" "$so done export LD_PRELOAD
6] run db2ldif
<inst>/ns-slapd db2ldif ............
@lkrispen thanks Ludwig it is indeed very precious. It could be added there http://www.port389.org/docs/389ds/howto/howto-addresssanitizer.html I will try to do this today
Metadata Update from @lkrispen: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/3529
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.