Memory leak or programing error

[Markus Moeller]

"Greg Hudson" <ghudson at MIT.EDU> wrote in message 
news:1251133842.20047.106.camel at ray...
> It looks like your test program relies on base64.h and presumably some
> source file, which you didn't include?
>
> I'm also not seeing your valgrind output in the attachment, but that is
> conceivably a problem on my end.  (Our mail server is known to mangle
> some messages.)
>

Ok I try to inline some valgrind output.  If you want to compile the test 
application please let me know I can send you the base64.h and .c file.

When I input GSSAPI tokens and all are successfully processed I get (the 
still reachable is fixed e.g. the same for inputing 1 or 20 tokens - so I 
think of no concern):

==15979== LEAK SUMMARY:
==15979==    definitely lost: 0 bytes in 0 blocks.
==15979==      possibly lost: 0 bytes in 0 blocks.
==15979==    still reachable: 637 bytes in 14 blocks.
==15979==         suppressed: 0 bytes in 0 blocks.

When I input a SPNEGO token and all are successfully processed I get:

==15993== LEAK SUMMARY:
==15993==    definitely lost: 0 bytes in 0 blocks.
==15993==      possibly lost: 0 bytes in 0 blocks.
==15993==    still reachable: 698 bytes in 19 blocks.
==15993==         suppressed: 0 bytes in 0 blocks.


Now when  I input GSSAPI token where number 2,3,4,...20 is a copy of the 
first (e.g. a replay) I get:

==15982== LEAK SUMMARY:
==15982==    definitely lost: 0 bytes in 0 blocks.
==15982==      possibly lost: 0 bytes in 0 blocks.
==15982==    still reachable: 637 bytes in 14 blocks.
==15982==         suppressed: 0 bytes in 0 blocks.


So far so good. But when I input a SPNEGO token where 2,3,4,...20 is a 
replay I get (which increases from 128 and 96 bytes respectively) :

==15996== LEAK SUMMARY:
==15996==    definitely lost: 1,280 bytes in 20 blocks.
==15996==    indirectly lost: 960 bytes in 60 blocks.
==15996==      possibly lost: 0 bytes in 0 blocks.
==15996==    still reachable: 698 bytes in 19 blocks.

and the origin seems to be:

==15996== 2,240 (1,280 direct, 960 indirect) bytes in 20 blocks are 
definitely lost in loss record 10 of 10
==15996==    at 0x4027DDE: malloc (in 
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==15996==    by 0x406B01E: create_spnego_ctx (spnego_mech.c:297)
==15996==    by 0x406C15B: spnego_gss_accept_sec_context (spnego_mech.c:941)
==15996==    by 0x404E61A: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==15996==    by 0x8049173: main (gssapi_auth_test.c:179)


Now lastely if I disable the replay cache (e.g.  export KRB5RCACHETYPE=none) 
and create errors because of time skew) I get for GSSAPI tokens (increasing 
from 136 bytes):

==28137== LEAK SUMMARY:
==28137==    definitely lost: 1,428 bytes in 21 blocks.
==28137==      possibly lost: 0 bytes in 0 blocks.
==28137==    still reachable: 637 bytes in 14 blocks.

and the origin being:

==28137== 1,428 bytes in 21 blocks are definitely lost in loss record 5 of 5
==28137==    at 0x4027DDE: malloc (in 
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==28137==    by 0x40E6EC9: krb5_rc_resolve_full (rc_base.c:152)
==28137==    by 0x40E411D: krb5_get_server_rcache (srv_rcache.c:107)
==28137==    by 0x405C22E: krb5_gss_acquire_cred (acquire_cred.c:192)
==28137==    by 0x4065E1D: k5glue_acquire_cred (krb5_gss_glue.c:460)
==28137==    by 0x404ED52: gss_add_cred (g_acquire_cred.c:382)
==28137==    by 0x404F2F1: gss_acquire_cred (g_acquire_cred.c:188)
==28137==    by 0x80493BF: main (gssapi_auth_test.c:223)

for SPNEGO tokens I get (from 400 and 96 bytes respectively):

==16108== LEAK SUMMARY:
==16108==    definitely lost: 4,200 bytes in 63 blocks.
==16108==    indirectly lost: 1,008 bytes in 63 blocks.
==16108==      possibly lost: 0 bytes in 0 blocks.
==16108==    still reachable: 698 bytes in 19 blocks.

the origin seems to be:

==16108== 2,352 (1,344 direct, 1,008 indirect) bytes in 21 blocks are 
definitely lost in loss record 10 of 11
==16108==    at 0x4027DDE: malloc (in 
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==16108==    by 0x406B01E: create_spnego_ctx (spnego_mech.c:297)
==16108==    by 0x406C15B: spnego_gss_accept_sec_context (spnego_mech.c:941)
==16108==    by 0x404E61A: gss_accept_sec_context 
(g_accept_sec_context.c:196)
==16108==    by 0x8049173: main (gssapi_auth_test.c:179)
==16108==
==16108==
==16108== 2,856 bytes in 42 blocks are definitely lost in loss record 11 of 
11
==16108==    at 0x4027DDE: malloc (in 
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==16108==    by 0x40E6EC9: krb5_rc_resolve_full (rc_base.c:152)
==16108==    by 0x40E411D: krb5_get_server_rcache (srv_rcache.c:107)
==16108==    by 0x405C22E: krb5_gss_acquire_cred (acquire_cred.c:192)
==16108==    by 0x4065E1D: k5glue_acquire_cred (krb5_gss_glue.c:460)
==16108==    by 0x404ED52: gss_add_cred (g_acquire_cred.c:382)
==16108==    by 0x404F2F1: gss_acquire_cred (g_acquire_cred.c:188)
==16108==    by 0x80490D1: main (gssapi_auth_test.c:171)

Regards
Markus

>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>