Hi Tom, I just tried the new release of 1.3 and it fixed all the leaking problems I've ever reported. Good, job well-done and it did give me a confidence boost to integrate this into our product. However I got a new chanllenge for you as well once I tested further. My program is using gss_init_sec_context() to do the kerberos authentication, so far by using 1.3, if everything goes well, no problem at all. However if something went wrong (for example, I didn't get TGT beforehand) then the first call to gss_init_sec_context() would fail, after that even though I've freed all the resources then it would still leak some memories. I think this problem is with regard to the graceful return from failure situation, there might be some other similar leaks since I have no way to try all possible failing scenarios. Below is the detailed report from SUN Workshop. Let me know if you guys will address this one soon. Thx. Kent XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Actual leaks report (actual leaks: 5 total size: 49 bytes) Total Num of Leaked Allocation call stack Size Blocks Block Address ====== ====== ========== ======================================= 20 1 0x2ebc0 krb5_fcc_resolve<-krb5_cc_resolve<-krb5_cc_default <-krb5int_cc_default<-acquire_init_cred<-krb5_gss_acquire_cred<-kg_get_defcred <-krb5_gss_init_sec_context 17 1 0x2ecf8 krb5_fcc_resolve<-krb5_cc_resolve<-krb5_cc_default <-krb5int_cc_default<-acquire_init_cred<-krb5_gss_acquire_cred<-kg_get_defcred <-krb5_gss_init_sec_context 12 1 0x2ce10 krb5_fcc_resolve<-krb5_cc_resolve<-krb5_cc_default <-krb5int_cc_default<-acquire_init_cred<-krb5_gss_acquire_cred<-kg_get_defcred <-krb5_gss_init_sec_context XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX -----Original Message----- From: Tom Yu via RT [mailto:rt-comment@krbdev.mit.edu] Sent: Tuesday, July 08, 2003 1:29 PM To: Kent Wu (RD-US) Cc: krb5-prs@mit.edu Subject: Re: [krbdev.mit.edu #1601] RE: [] RE: memory leak in some Kerberos APIs? >>>>> "Kent" == Kent Wu@trendmicro com via RT 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