[krbdev.mit.edu #1601] RE: [<Kent_Wu@trendmicro.com>] RE: memory leak in some Kerberos APIs?

[Kent_Wu@trendmicro.com via RT]

Tom,

	Last question, can you tell me when approximately you guys will release 1.3, just want to make sure we can be in line with your release.

Thx.

Kent

-----Original Message-----
From: Tom Yu via RT [mailto:rt-comment at krbdev.mit.edu]
Sent: Tuesday, July 08, 2003 1:29 PM
To: Kent Wu (RD-US)
Cc: krb5-prs at mit.edu
Subject: Re: [krbdev.mit.edu #1601] RE: [<Kent_Wu at trendmicro.com>] RE:
memory leak in some Kerberos APIs?


>>>>> "Kent" == Kent Wu at trendmicro com via RT <rt-comment at krbdev.mit.edu> writes:

Kent> 	I found my program wasn't complete in authentication so that I
Kent> 	enhanced it to be complete in terms of kerberos
Kent> 	authentication, after that I used SUN LDAP API to do some
Kent> 	search. By doing this I also found some new leaks, not sure if
Kent> 	you have addressed these in the new Beta or not, pls let me
Kent> 	know so that I can give the new Beta a try. I'm still using
Kent> 	Beta 3 now.

The current beta is krb5-1.3-beta5.

Kent> OLD LEAKS: For the first one you mentioned that might be a
Kent> system bug, is this for sure now? I assume 2rd has been taken
Kent> care of, not sure if you've really addressed 3rd or not since
Kent> last time you said it's difficult to take on.

Kent>     32       2      -       get_addr<-getaddrinfo
Kent>     24       1    0x30c58   make_gss_checksum<-make_ap_req_v1<-
Kent> krb5_gss_init_sec_context<-gss_init_sec_context<-main
Kent>      8       1    0x2f708   get_profile_etype_list<-krb5_get_tgs_ktypes<-
Kent> krb5_gss_init_sec_context<-gss_init_sec_context<-main

I'm fairly certain that the getaddrinfo leak is an OS bug, as I'm not
seeing it on my Solaris 8 machine.  The other two leaks have already
been addressed in tickets #1602 and #1604.

Kent> NEW LEAKS: Pls let me know if you have addressed this in the new
Kent> Beta. The last one might be from LDAP SDK.

Kent>     16       1    0x2c698   krb5_generate_subkey<-krb5_mk_req_extended<-
Kent> make_ap_req_v1<-krb5_gss_init_sec_context<-gss_init_sec_context<-main
Kent>     16       1    0x2c710   krb5_copy_keyblock<-krb5_mk_req_extended<-
Kent> make_ap_req_v1<-krb5_gss_init_sec_context<-gss_init_sec_context<-main
Kent>      8       1    0x2f788   krb5_copy_keyblock<-krb5_mk_req_extended<-
Kent> make_ap_req_v1<-krb5_gss_init_sec_context<-gss_init_sec_context<-main
Kent>      8       1    0x2f7e8   krb5_c_make_random_key<-krb5_generate_subkey<-
Kent> krb5_mk_req_extended<-make_ap_req_v1<-krb5_gss_init_sec_context<-
Kent> gss_init_sec_context<-main
Kent>      2       2      -       ber_get_stringa<-ber_scanf

The mk_req_extended leaks were dealt with in bug #1605.  The last one
does look like it might be from code that is not ours, as the function
names don't exist in our code.

---Tom