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