Tom, yes that solves this one: ==9846== 1,282 bytes in 1 blocks are definitely lost in loss record 35 of 36 ==9846== at 0x40235B5: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==9846== by 0x4046673: make_ap_req_v1 (init_sec_context.c:320) ==9846== by 0x4046D74: new_connection (init_sec_context.c:561) ==9846== by 0x4047C95: krb5_gss_init_sec_context (init_sec_context.c:943) ==9846== by 0x404D080: k5glue_init_sec_context (krb5_gss_glue.c:675) ==9846== by 0x403473E: gss_init_sec_context (g_init_sec_context.c:211) ==9846== by 0x4052DA9: init_ctx_call_init (spnego_mech.c:687) ==9846== by 0x4052FF9: spnego_gss_init_sec_context (spnego_mech.c:801) ==9846== by 0x403473E: gss_init_sec_context (g_init_sec_context.c:211) Markus ----- Original Message ----- From: "Tom Yu via RT" To: Sent: Tuesday, August 07, 2007 9:15 PM Subject: Re: [krbdev.mit.edu #5629] gss_init_sec_context does not release output token buffer when used with spnego mech > Please try the following patch and let us know if it resolves the > output token buffer leak. > > Index: src/lib/gssapi/spnego/spnego_mech.c > =================================================================== > --- src/lib/gssapi/spnego/spnego_mech.c (revision 19756) > +++ src/lib/gssapi/spnego/spnego_mech.c (revision 19757) > @@ -835,6 +835,7 @@ > ret = GSS_S_FAILURE; > } > } > + gss_release_buffer(tmpmin, &mechtok_out); > if (ret == GSS_S_COMPLETE) { > /* > * Now, switch the output context to refer to the > > >