Re: memory leak in krb5_rd_cred

[Howard Chu <hyc@highlandsun.com>]

Henry B. Hotz wrote:
>
> 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.
>
> |-P
>
> Been using the above mentioned fix, so not sure how much I care, but 
> it might come back to haunt me.

Perhaps it was just unable to backtrack far enough in the call stack to 
identify the original caller.  (Or more to the point, it was unable to 
make sense of the call stack at all, which happens a lot with optimized 
libraries.) I've only used libumem as a basic malloc replacement, never 
tried out any of its other features. It's a nice malloc library, to be 
sure, although the last time I checked it had some non-portable 
assumptions about word size. (I submitted a few patches to get it to run 
cleanly on AMD64.)
>
> ------
>
> 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. ;-)

Yeah, I've built code using MIT headers with the Sun libraries. I 
consider that a desperate measure, especially given the MIT code's lousy 
behavior in a threaded program.
>
> That becomes moot in June when S10 u4 is released.  It's supposed to 
> open up the MIT API.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  Chief Architect, OpenLDAP     http://www.openldap.org/project/