new memory leak in gss_init_sec_context()?

[Kent_Wu@trendmicro.com]

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 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