Ticket History #166: memory leak in svc_auth_gssapi

From bjaspan@MIT.EDU Thu Nov 7 15:23:29 1996
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id PAA26674 for <bugs@RT-11.MIT.EDU>; Thu, 7 Nov 1996 15:23:29 -0500
Received: from BEEBLEBROX.MIT.EDU by MIT.EDU with SMTP
id AA18576; Thu, 7 Nov 96 15:23:28 EST
Received: by beeblebrox.MIT.EDU (940816.SGI.8.6.9/4.7) id UAA29944; Thu, 7 Nov 1996 20:23:26 GMT
Message-Id: <199611072023.UAA29944@beeblebrox.MIT.EDU>
Date: Thu, 7 Nov 1996 20:23:26 GMT
From: bjaspan@MIT.EDU
Reply-To: bjaspan@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: memory leak in svc_auth_gssapi
X-Send-Pr-Version: 3.99

mit

System: IRIX beeblebrox 5.3 11091812 IP22 mips



The kadm5 unit tests reveal the following memory leaks, apparently in
the RPC:

This memory was allocated from:
_malloc [malloc.c:761]
create_client [svc_auth_gssapi.c:841]
_svcauth_gssapi [svc_auth_gssapi.c:390]
_authenticate [svc_auth.c:103]
svc_getreqset [svc.c:448]
kadm_svc_run [ovsec_kadmd.c:440]
main [ovsec_kadmd.c:384]
__start [crt1text.s:133]
Block of 48 bytes (22 times); last block at 0x103d7348

MLK: 1007 bytes leaked in 19 blocks
This memory was allocated from:
_malloc [malloc.c:761]
make_seal_token [k5seal.c:67]
kg_seal [k5seal.c:322]
krb5_gss_seal [seal.c:46]
gss_seal [krb5_gss_glue.c:402]
auth_gssapi_seal_seq [auth_gssapi_misc.c:197]
_svcauth_gssapi [svc_auth_gssapi.c:691]
_authenticate [svc_auth.c:103]
svc_getreqset [svc.c:448]
kadm_svc_run [ovsec_kadmd.c:440]
main [ovsec_kadmd.c:384]
__start [crt1text.s:133]
Block of 53 bytes (19 times); last block at 0x103c7148

There are other leaks that lose 1-200 bytes over the course of the
KADM5 unit tests; see lib/kadm5/unit-test/kadmind.pure.pv in the build
tree on beeblebrox.




From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: bjaspan@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-libs/166: memory leak in svc_auth_gssapi
Date: Mon, 11 Nov 1996 15:45:17 -0500

I'm not convinced these are actually memory leaks. I killed kadmind
after the tests had completed, so perhaps these are just the client
entries that were still in memory at the time.

Of course, I think all the clients are disconnecting properly so they
shouldn't leave entries lying around...

Barry

State-Changed-From-To: open-closed
State-Changed-By: bjaspan
State-Changed-When: Mon Nov 18 15:32:12 1996
State-Changed-Why:

I no longer believe this is a memory leak.