[Swan-dev] Pluto memory consumption
Andrew Cagney
andrew.cagney at gmail.com
Tue Feb 28 15:34:48 UTC 2017
On 28 February 2017 at 09:28, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
> NSS does its own memory allocation and is thus invisible to the leak
> detective. Anything NSS-related is thus suspect. Think: keys and
> related stuff. So you are probably on the right track.
>
> | ==2935== 5,095,216 bytes in 938 blocks are still reachable in loss record 652
>
> | ==2935== at 0x4C2B975: calloc (vg_replace_malloc.c:711)
> | ==2935== by 0x6B3B351: PORT_ZAlloc_Util (in /usr/lib64/libnssutil3.so)
>
> | ==2935== by 0x16B228: symkey_from_symkey (crypt_symkey.c:283)
Yea, a simpler one is:
==2935== 16 bytes in 1 blocks are still reachable in loss record 38 of 653
==2935== at 0x4C29BE3: malloc (vg_replace_malloc.c:299)
==2935== by 0x6B3B27F: PORT_Alloc_Util (in /usr/lib64/libnssutil3.so)
==2935== by 0x4E79E59: ??? (in /usr/lib64/libnss3.so)
==2935== by 0x4E8428C: PK11_ExtractKeyValue (in /usr/lib64/libnss3.so)
==2935== by 0x4E84567: ??? (in /usr/lib64/libnss3.so)
==2935== by 0x4E854DB: PK11_DeriveWithTemplate (in /usr/lib64/libnss3.so)
==2935== by 0x4E85720: PK11_Derive (in /usr/lib64/libnss3.so)
==2935== by 0x16B0BF: merge_symkey_bytes (crypt_symkey.c:222)
==2935== by 0x16BD72: symkey_from_bytes (crypt_symkey.c:376)
==2935== by 0x1336A1: decode_to_key (test_buffer.c:157)
==2935== by 0x132811: test_cbc_vector (cbc_test_vectors.c:83)
==2935== by 0x132811: test_cbc_vectors (cbc_test_vectors.c:111)
==2935== by 0x13425E: init_crypto (crypto.c:52)
where the code looks like:
PK11SymKey *sym_key = decode_to_key(encrypt_desc, test->key);
if (!test_cbc_op(encrypt_desc, test->description, 1,
sym_key, test->iv,
"plaintext: ", test->plaintext,
"ciphertext: ", test->ciphertext)) {
ok = FALSE;
}
if (!test_cbc_op(encrypt_desc, test->description, 0,
sym_key, test->iv,
"cipertext: ", test->ciphertext,
"plaintext: ", test->plaintext)) {
ok = FALSE;
}
/* Clean up. */
free_any_symkey("sym_key", &sym_key);
so from our POV the key was freed. However NSS has kept a handle on
that memory and will recycle it repeatedly.
More information about the Swan-dev
mailing list