memory leak from within libp11-kit-1 (maybe a module not getting properly unloaded?)

Stef Walter stefw at redhat.com
Mon Feb 18 11:17:25 PST 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/16/2013 06:52 AM, Daniel Kahn Gillmor wrote:
> I wrote the following simple program using p11-kit 0.14-1 on
> debian unstable (libc6 2.13:
> 
> --------- #include <p11-kit/p11-kit.h>
> 
> int main() { p11_kit_initialize_registered(); 
> p11_kit_finalize_registered(); } ---------
> 
> Only one module is configured on this system, from gnome-keyring
> 3.6.1-1:
> 
> 0 dkg at alice:~$ head -v -n 20 /etc/pkcs11/modules/* ==>
> /etc/pkcs11/modules/gnome-keyring.module <==
> 
> # The file is installed/loaded from the default module p11-kit
> directory module: gnome-keyring-pkcs11.so
> 
> # And where to store and lookup trust objects x-trust-store:
> pkcs11:library-manufacturer=GNOME%20Keyring;serial=1:XDG:DEFAULT 
> x-trust-lookup: pkcs11:library-manufacturer=GNOME%20Keyring 0
> dkg at alice:~$ dpkg -l gnome-keyring 
> Desired=Unknown/Install/Remove/Purge/Hold |
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>
> 
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name           Version      Architecture Description 
> +++-==============-============-============-=================================
>
> 
ii  gnome-keyring  3.6.1-1      amd64        GNOME keyring services
(daemon an
> 0 dkg at alice:~$
> 
> 
> When i run the above program under valgrind, i get the following:
> 
> 0 dkg at alice:~$ valgrind  --leak-check=full  --show-reachable=yes --
> ./p11kittest ==30409== Memcheck, a memory error detector ==30409==
> Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. 
> ==30409== Using Valgrind-3.7.0 and LibVEX; rerun with -h for
> copyright info ==30409== Command: ./p11kittest ==30409== ==30409==
>  ==30409== HEAP SUMMARY: ==30409==     in use at exit: 32 bytes in
> 1 blocks ==30409==   total heap usage: 44 allocs, 43 frees, 38,180
> bytes allocated ==30409== ==30409== 32 bytes in 1 blocks are still
> reachable in loss record 1 of 1 ==30409==    at 0x4C272B8: calloc
> (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==30409==
> by 0x53CE35F: _dlerror_run (dlerror.c:142) ==30409==    by
> 0x53CDEE0: dlopen@@GLIBC_2.2.5 (dlopen.c:88) ==30409==    by
> 0x4E3468A: dlopen_and_get_function_list (in
> /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.0.0) ==30409==    by
> 0x4E3543F: _p11_kit_initialize_registered_unlocked_reentrant (in
> /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.0.0) ==30409==    by
> 0x4E3583B: p11_kit_initialize_registered (in
> /usr/lib/x86_64-linux-gnu/libp11-kit.so.0.0.0) ==30409==    by
> 0x400644: main (p11kittest.c:4) ==30409== ==30409== LEAK SUMMARY: 
> ==30409==    definitely lost: 0 bytes in 0 blocks ==30409==
> indirectly lost: 0 bytes in 0 blocks ==30409==      possibly lost:
> 0 bytes in 0 blocks ==30409==    still reachable: 32 bytes in 1
> blocks ==30409==         suppressed: 0 bytes in 0 blocks ==30409==
>  ==30409== For counts of detected and suppressed errors, rerun
> with: -v ==30409== ERROR SUMMARY: 0 errors from 0 contexts
> (suppressed: 7 from 7)
> 
> 
> Is it possible that the module in question is not being properly 
> dlclose()'ed?
> 
> Sorry that i haven't had the chance yet to test this against a
> more recent version or to debug it in more depth.

Interesting.

You can use the P11_KIT_DEBUG=all environment variable to get debug
output and see more details about what's going on. If there's not
enough detail, could you add a debug statement near the dlclose() and
see if it's getting called?

Cheers,

Stef

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlEifkUACgkQe/sRCNknZa8UnwCeLwM85a8ID3XyH2GoKs13hgGL
EJQAnRLREVRT/aJ2zUivELurGjZ3YlJq
=Id/r
-----END PGP SIGNATURE-----


More information about the p11-glue mailing list