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

# Fri Jun 13 00:41:36 2003 tlyu (Taylor Yu) - Ticket created

To:	rt-krb5@krbdev.mit.edu
Cc:	<Kent_Wu@trendmicro.com>
Subject:	[<Kent_Wu@trendmicro.com>] RE: memory leak in some Kerberos APIs?
From:	Tom Yu <tlyu@mit.edu>
Date:	Fri, 13 Jun 2003 00:41:33 -0400

Download (untitled) / with headers
text/plain 3.5KiB

Forwarding this to the bug database...

Have confirmed and located the leak in make_ap_req_v1. Haven't seen
the getaddrinfo leak yet, though it could be due to failure to call
release_name. The get_profile_etype_list leak looks somewhat
difficult to deal with, though, and it's been around a while so I'm
not inclined to give it high priority.

---Tom

Show quoted text

-------------------- Start of forwarded message --------------------
From: <Kent_Wu@trendmicro.com>
To: <tlyu@mit.edu>
cc: krbdev@mit.edu
Subject: RE: memory leak in some Kerberos APIs?
Lines: 80

Tom:

I just gave it a shot and Bingo, you guys did fix the memory leak in those preauth code. However it introduced some other new leaks in GSS-API side as well. The last one from get_profile_etype_list() is actually the same as last time, it didn't get fixed. The first two are new leaks. Here is the detailed report:

Actual leaks report (actual leaks: 3 total size: 48 bytes)
Total Num of Leaked Allocation call stack
Size Blocks Block
Address
====== ====== ========== =======================================
24 1 0x2e878 make_gss_checksum<-make_ap_req_v1<-
krb5_gss_init_sec_context<-gss_init_sec_context<-main
16 1 0x2c5e0 get_addr<-getaddrinfo<-krb5_sname_to_principal<-
krb5_gss_import_name<-gss_import_name<-main
8 1 0x2d170 get_profile_etype_list<-krb5_get_tgs_ktypes<-
krb5_gss_init_sec_context<-gss_init_sec_context<-main

Let me know if you guys fix it and put on a new Beta candidate.

Thx.

Kent

-----Original Message-----
From: Kent Wu (RD-US)
Sent: Thursday, June 12, 2003 4:42 PM
To: tlyu@mit.edu
Cc: krbdev@mit.edu
Subject: RE: memory leak in some Kerberos APIs?

Hi, Tom:

I'll give it a try and let us know when it got released.

Thx.

Kent

-----Original Message-----
From: Tom Yu [mailto:tlyu@mit.edu]
Sent: Thursday, June 12, 2003 3:51 PM
To: Kent Wu (RD-US)
Cc: krbdev@mit.edu
Subject: Re: memory leak in some Kerberos APIs?

>>>>> "Kent_Wu" == <Kent_Wu@trendmicro.com> writes:

Kent_Wu> Actual leaks report (actual leaks: 4 total size: 57 bytes)
Kent_Wu> Total Num of Leaked Allocation call stack
Kent_Wu> Size Blocks Block
Kent_Wu> Address
Kent_Wu> ====== ====== ========== =======================================
Kent_Wu> 25 1 0x2bbd8 asn1buf_remove_octetstring<-
Kent_Wu> asn1_decode_octetstring<-asn1_decode_etype_info_entry<-asn1_decode_etype_info
Kent_Wu> <-decode_krb5_etype_info<-krb5_do_preauth<-krb5_get_init_creds<-
Kent_Wu> krb5_get_init_creds_password

Kent_Wu> 16 1 0x2ab88 calloc<-asn1_decode_etype_info<-
Kent_Wu> decode_krb5_etype_info<-krb5_do_preauth<-krb5_get_init_creds<-
Kent_Wu> krb5_get_init_creds_password<-main

Kent_Wu> 8 1 0x2b2b8 get_profile_etype_list<-krb5_get_tgs_ktypes<-
Kent_Wu> krb5_gss_init_sec_context<-gss_init_sec_context<-main

Kent_Wu> 8 1 0x36248 asn1_decode_etype_info<-decode_krb5_etype_info<-
Kent_Wu> krb5_do_preauth<-krb5_get_init_creds<-krb5_get_init_creds_password<-main

Have you tried compiling with one of the beta releases of krb5-1.3? I
seem to recall that we have fixed some preauth-related memorly leaks.

---Tom

_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

-------------------- End of forwarded message --------------------

# Fri Jun 13 13:13:52 2003 <Kent_Wu@trendmicro.com> - Ticket #1603: - Ticket created

From:	Kent_Wu@trendmicro.com
Subject:	RE: [<Kent_Wu@trendmicro.com>] RE: memory leak in some Kerberos APIs?
Date:	Fri, 13 Jun 2003 10:13:35 -0700
To:	<tlyu@mit.edu>, <rt-krb5@krbdev.mit.edu>

Download (untitled) / with headers
text/plain 4KiB

Thx for the update, Tom. However if possible could you still pls try to fix the get_profile_etype_list one since our service will keep doing the authentication so this leaking problem will have accumulative effect, then eventually it would still cause a problem.

Thx.

Kent

Show quoted text

-----Original Message-----
From: Tom Yu [mailto:tlyu@mit.edu]
Sent: Thursday, June 12, 2003 9:42 PM
To: rt-krb5@krbdev.mit.edu
Cc: Kent Wu (RD-US)
Subject: [<Kent_Wu@trendmicro.com>] RE: memory leak in some Kerberos
APIs?

Forwarding this to the bug database...

Have confirmed and located the leak in make_ap_req_v1. Haven't seen
the getaddrinfo leak yet, though it could be due to failure to call
release_name. The get_profile_etype_list leak looks somewhat
difficult to deal with, though, and it's been around a while so I'm
not inclined to give it high priority.

---Tom

-------------------- Start of forwarded message --------------------
From: <Kent_Wu@trendmicro.com>
To: <tlyu@mit.edu>
cc: krbdev@mit.edu
Subject: RE: memory leak in some Kerberos APIs?
Lines: 80

Tom:

I just gave it a shot and Bingo, you guys did fix the memory leak in those preauth code. However it introduced some other new leaks in GSS-API side as well. The last one from get_profile_etype_list() is actually the same as last time, it didn't get fixed. The first two are new leaks. Here is the detailed report:

Actual leaks report (actual leaks: 3 total size: 48 bytes)
Total Num of Leaked Allocation call stack
Size Blocks Block
Address
====== ====== ========== =======================================
24 1 0x2e878 make_gss_checksum<-make_ap_req_v1<-
krb5_gss_init_sec_context<-gss_init_sec_context<-main
16 1 0x2c5e0 get_addr<-getaddrinfo<-krb5_sname_to_principal<-
krb5_gss_import_name<-gss_import_name<-main
8 1 0x2d170 get_profile_etype_list<-krb5_get_tgs_ktypes<-
krb5_gss_init_sec_context<-gss_init_sec_context<-main

Let me know if you guys fix it and put on a new Beta candidate.

Thx.

Kent

-----Original Message-----
From: Kent Wu (RD-US)
Sent: Thursday, June 12, 2003 4:42 PM
To: tlyu@mit.edu
Cc: krbdev@mit.edu
Subject: RE: memory leak in some Kerberos APIs?

Hi, Tom:

I'll give it a try and let us know when it got released.

Thx.

Kent

-----Original Message-----
From: Tom Yu [mailto:tlyu@mit.edu]
Sent: Thursday, June 12, 2003 3:51 PM
To: Kent Wu (RD-US)
Cc: krbdev@mit.edu
Subject: Re: memory leak in some Kerberos APIs?

>>>>> "Kent_Wu" == <Kent_Wu@trendmicro.com> writes:

Kent_Wu> Actual leaks report (actual leaks: 4 total size: 57 bytes)
Kent_Wu> Total Num of Leaked Allocation call stack
Kent_Wu> Size Blocks Block
Kent_Wu> Address
Kent_Wu> ====== ====== ========== =======================================
Kent_Wu> 25 1 0x2bbd8 asn1buf_remove_octetstring<-
Kent_Wu> asn1_decode_octetstring<-asn1_decode_etype_info_entry<-asn1_decode_etype_info
Kent_Wu> <-decode_krb5_etype_info<-krb5_do_preauth<-krb5_get_init_creds<-
Kent_Wu> krb5_get_init_creds_password

Kent_Wu> 16 1 0x2ab88 calloc<-asn1_decode_etype_info<-
Kent_Wu> decode_krb5_etype_info<-krb5_do_preauth<-krb5_get_init_creds<-
Kent_Wu> krb5_get_init_creds_password<-main

Kent_Wu> 8 1 0x2b2b8 get_profile_etype_list<-krb5_get_tgs_ktypes<-
Kent_Wu> krb5_gss_init_sec_context<-gss_init_sec_context<-main

Kent_Wu> 8 1 0x36248 asn1_decode_etype_info<-decode_krb5_etype_info<-
Kent_Wu> krb5_do_preauth<-krb5_get_init_creds<-krb5_get_init_creds_password<-main

Have you tried compiling with one of the beta releases of krb5-1.3? I
seem to recall that we have fixed some preauth-related memorly leaks.

---Tom

_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

-------------------- End of forwarded message --------------------

# Fri Jun 13 17:17:48 2003 raeburn (Ken Raeburn) - Ticket #1603: - Ticket 1603 MergedInto ticket 1601.

# Tue Jun 17 02:56:06 2003 tlyu (Taylor Yu) - Correspondence added

To:	rt@krbdev.mit.edu
Subject:	Re: [krbdev.mit.edu #1601] [<Kent_Wu@trendmicro.com>] RE: memory leak in some Kerberos APIs?
From:	Tom Yu <tlyu@mit.edu>
Date:	Tue, 17 Jun 2003 02:56:04 -0400
RT-Send-Cc:

Download (untitled) / with headers
text/plain 716B

Two of the three memory leaks noted in this ticket have their own
tickets -- [1602] and [1604]. [1602] is the checksum leak, and [1604]
is the ktypes leak. The getaddrinfo() leak we have not been able to
reproduce, and I am inclined to believe that it is an OS bug.

The return addrinfo structure from getaddrinfo() is significantly
larger than 16 bytes, so we are not leaking that. Note, however, that
a struct sockaddr is 16 bytes on sparc/solaris, and it's quite
plausible that what you're seeing is an artifact of an OS bug.

The latest beta release (krb5-1.3-beta4) should have fixes for [1602]
and [1604]. I'm closing this bug [1601] for now, since I'm fairly
convinced it's not a bug in our code.

---Tom

# Tue Jun 17 02:57:34 2003 tlyu (Taylor Yu) - Status changed from 'new' to 'resolved'

# Tue Jun 17 02:57:34 2003 tlyu (Taylor Yu) - Version_reported 1.3 added

# Tue Jun 17 02:57:34 2003 tlyu (Taylor Yu) - Tags nochange added

# Tue Jun 17 02:58:24 2003 tlyu (Taylor Yu) - Component krb5-libs added

# Tue Jun 17 14:56:18 2003 <Kent_Wu@trendmicro.com> - Comments added

From:	Kent_Wu@trendmicro.com
Subject:	RE: [krbdev.mit.edu #1601] [<Kent_Wu@trendmicro.com>] RE: memory leak in some Kerberos APIs?
Date:	Tue, 17 Jun 2003 11:55:40 -0700
To:	<rt-comment@krbdev.mit.edu>
RT-Send-Cc:

Download (untitled) / with headers
text/plain 1.1KiB

Thx for the update, Tom. I'll try the latest Beta later when I got time. One more question is when will you plan to release 1.3, I hope it can be in line with our release as well.

Kent

Show quoted text

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

Two of the three memory leaks noted in this ticket have their own
tickets -- [1602] and [1604]. [1602] is the checksum leak, and [1604]
is the ktypes leak. The getaddrinfo() leak we have not been able to
reproduce, and I am inclined to believe that it is an OS bug.

The return addrinfo structure from getaddrinfo() is significantly
larger than 16 bytes, so we are not leaking that. Note, however, that
a struct sockaddr is 16 bytes on sparc/solaris, and it's quite
plausible that what you're seeing is an artifact of an OS bug.

The latest beta release (krb5-1.3-beta4) should have fixes for [1602]
and [1604]. I'm closing this bug [1601] for now, since I'm fairly
convinced it's not a bug in our code.

---Tom

# Mon Jul 07 19:29:05 2003 <Kent_Wu@trendmicro.com> - Ticket #1653: - Ticket created

From:	Kent_Wu@trendmicro.com
Subject:	RE: [<Kent_Wu@trendmicro.com>] RE: memory leak in some Kerberos APIs?
Date:	Mon, 7 Jul 2003 16:27:56 -0700
To:	<tlyu@mit.edu>, <rt-krb5@krbdev.mit.edu>

Download (untitled) / with headers
text/plain 5.6KiB

Hi, Tom,

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

Thx.

Kent

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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

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

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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

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

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Thx alot.

Show quoted text

-----Original Message-----
From: Tom Yu [mailto:tlyu@mit.edu]
Sent: Thursday, June 12, 2003 9:42 PM
To: rt-krb5@krbdev.mit.edu
Cc: Kent Wu (RD-US)
Subject: [<Kent_Wu@trendmicro.com>] RE: memory leak in some Kerberos
APIs?

Forwarding this to the bug database...

Have confirmed and located the leak in make_ap_req_v1. Haven't seen
the getaddrinfo leak yet, though it could be due to failure to call
release_name. The get_profile_etype_list leak looks somewhat
difficult to deal with, though, and it's been around a while so I'm
not inclined to give it high priority.

---Tom

-------------------- Start of forwarded message --------------------
From: <Kent_Wu@trendmicro.com>
To: <tlyu@mit.edu>
cc: krbdev@mit.edu
Subject: RE: memory leak in some Kerberos APIs?
Lines: 80

Tom:

I just gave it a shot and Bingo, you guys did fix the memory leak in those preauth code. However it introduced some other new leaks in GSS-API side as well. The last one from get_profile_etype_list() is actually the same as last time, it didn't get fixed. The first two are new leaks. Here is the detailed report:

Actual leaks report (actual leaks: 3 total size: 48 bytes)
Total Num of Leaked Allocation call stack
Size Blocks Block
Address
====== ====== ========== =======================================
24 1 0x2e878 make_gss_checksum<-make_ap_req_v1<-
krb5_gss_init_sec_context<-gss_init_sec_context<-main
16 1 0x2c5e0 get_addr<-getaddrinfo<-krb5_sname_to_principal<-
krb5_gss_import_name<-gss_import_name<-main
8 1 0x2d170 get_profile_etype_list<-krb5_get_tgs_ktypes<-
krb5_gss_init_sec_context<-gss_init_sec_context<-main

Let me know if you guys fix it and put on a new Beta candidate.

Thx.

Kent

-----Original Message-----
From: Kent Wu (RD-US)
Sent: Thursday, June 12, 2003 4:42 PM
To: tlyu@mit.edu
Cc: krbdev@mit.edu
Subject: RE: memory leak in some Kerberos APIs?

Hi, Tom:

I'll give it a try and let us know when it got released.

Thx.

Kent

-----Original Message-----
From: Tom Yu [mailto:tlyu@mit.edu]
Sent: Thursday, June 12, 2003 3:51 PM
To: Kent Wu (RD-US)
Cc: krbdev@mit.edu
Subject: Re: memory leak in some Kerberos APIs?

>>>>> "Kent_Wu" == <Kent_Wu@trendmicro.com> writes:

Kent_Wu> Actual leaks report (actual leaks: 4 total size: 57 bytes)
Kent_Wu> Total Num of Leaked Allocation call stack
Kent_Wu> Size Blocks Block
Kent_Wu> Address
Kent_Wu> ====== ====== ========== =======================================
Kent_Wu> 25 1 0x2bbd8 asn1buf_remove_octetstring<-
Kent_Wu> asn1_decode_octetstring<-asn1_decode_etype_info_entry<-asn1_decode_etype_info
Kent_Wu> <-decode_krb5_etype_info<-krb5_do_preauth<-krb5_get_init_creds<-
Kent_Wu> krb5_get_init_creds_password

Kent_Wu> 16 1 0x2ab88 calloc<-asn1_decode_etype_info<-
Kent_Wu> decode_krb5_etype_info<-krb5_do_preauth<-krb5_get_init_creds<-
Kent_Wu> krb5_get_init_creds_password<-main

Kent_Wu> 8 1 0x2b2b8 get_profile_etype_list<-krb5_get_tgs_ktypes<-
Kent_Wu> krb5_gss_init_sec_context<-gss_init_sec_context<-main

Kent_Wu> 8 1 0x36248 asn1_decode_etype_info<-decode_krb5_etype_info<-
Kent_Wu> krb5_do_preauth<-krb5_get_init_creds<-krb5_get_init_creds_password<-main

Have you tried compiling with one of the beta releases of krb5-1.3? I
seem to recall that we have fixed some preauth-related memorly leaks.

---Tom

_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

-------------------- End of forwarded message --------------------

# Tue Jul 08 16:29:16 2003 tlyu (Taylor Yu) - Correspondence added

To:	rt@krbdev.mit.edu
Subject:	Re: [krbdev.mit.edu #1601] RE: [<Kent_Wu@trendmicro.com>] RE: memory leak in some Kerberos APIs?
From:	Tom Yu <tlyu@mit.edu>
Date:	Tue, 08 Jul 2003 16:29:15 -0400
RT-Send-Cc:

Download (untitled) / with headers
text/plain 2.2KiB

Show quoted text

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

Show quoted text

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.

Show quoted text

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.

Show quoted text

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.

Show quoted text

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.

Show quoted text

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

# Tue Jul 08 16:47:15 2003 <Kent_Wu@trendmicro.com> - Comments added

From:	Kent_Wu@trendmicro.com
Subject:	RE: [krbdev.mit.edu #1601] RE: [<Kent_Wu@trendmicro.com>] RE: memory leak in some Kerberos APIs?
Date:	Tue, 8 Jul 2003 13:46:36 -0700
To:	<rt-comment@krbdev.mit.edu>
RT-Send-Cc:

Download (untitled) / with headers
text/plain 2.5KiB

So I guess all the fix should reflect in beta6?

Thx.

Kent

Show quoted text

-----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: [<Kent_Wu@trendmicro.com>] RE:
memory leak in some Kerberos APIs?

>>>>> "Kent" == Kent Wu@trendmicro com via RT <rt-comment@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

# Tue Jul 08 16:49:28 2003 tlyu (Taylor Yu) - Correspondence added

To:	rt@krbdev.mit.edu
Subject:	Re: [krbdev.mit.edu #1601] RE: [<Kent_Wu@trendmicro.com>] RE: memory leak in some Kerberos APIs?
From:	Tom Yu <tlyu@mit.edu>
Date:	Tue, 08 Jul 2003 16:49:26 -0400
RT-Send-Cc:

Download (untitled) / with headers
text/plain 215B

Show quoted text

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

Show quoted text

Kent> So I guess all the fix should reflect in beta6?

No... beta5 should already have all the mentioned memory leak fixes.

---Tom

# Tue Jul 08 17:37:00 2003 <Kent_Wu@trendmicro.com> - Comments added

From:	Kent_Wu@trendmicro.com
Subject:	RE: [krbdev.mit.edu #1601] RE: [<Kent_Wu@trendmicro.com>] RE: memory leak in some Kerberos APIs?
Date:	Tue, 8 Jul 2003 14:36:26 -0700
To:	<rt-comment@krbdev.mit.edu>
RT-Send-Cc:

Download (untitled) / with headers
text/plain 2.6KiB

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

Show quoted text

-----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: [<Kent_Wu@trendmicro.com>] RE:
memory leak in some Kerberos APIs?

>>>>> "Kent" == Kent Wu@trendmicro com via RT <rt-comment@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