[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: memory leak in krb5_rd_cred

On Feb 20, 2007, at 6:52 PM, Howard Chu wrote:

>>> I have  an app with a slow leak that uses it, but I can't be sure  
>>> it doesn't  have to do with funny linking conflicts or external  
>>> issues.  The leak  goes away if I link against Sun Kerberos, but  
>>> I'm not supposed to do  that. ;-)
>> Tried valgrind? That's how I found this leak in the first place.
> valgrind is definitely cool, for Linux. There are other good malloc  
> debuggers out there. FunctionCheck works on Linux and Solaris.   
> http://www.highlandsun.com/hyc/#fncchk

I used the Sun malloc debugger, libumem.  The functionality appears  
fine, but I can't compare it to anything.  It said unequivocally that  
I did not have a leak, but some unrelated Sun library did.  Remove my  
code and the other library suddenly no longer has a leak.


Been using the above mentioned fix, so not sure how much I care, but  
it might come back to haunt me.


This is definitely off-topic, but Sun's version of the Kerberos  
libraries is in /usr/lib/gss/gl/mech_krb5.so.  It's originally based  
off of MIT 1.2.1, so if you compare the krb5.h definitions in 1.2.1  
with what's in current OpenSolaris and there's no difference you're  
pretty safe assuming the definition is valid for Solaris 9 or 10 as  
well.  (I hope Nico doesn't kill me for saying that. ;-)

That becomes moot in June when S10 u4 is released.  It's supposed to  
open up the MIT API.
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu