[Date Prev][Date Next]
RE: ldap_sasl_interactive_bind_s leaks? (ITS#2423)
On Sat, 5 Apr 2003, Howard Chu wrote:
> > -----Original Message-----
> > From: Igor Brezac [mailto:email@example.com]
> > On Sat, 5 Apr 2003, Howard Chu wrote:
> > > > Anyway,
> > > > ldap_sasl_interactive_bind_s() frees
> > > > SASL_INTERACT prompt result, but I do not think it frees
> > > > other prompt buffers.
> > > > I looked throught sources for ldapsearch and slurpd, but I
> > > > did not find ways to
> > > > free the buffers allocated in _ldap_interact.
> > > It appears that _ldap_interact doesn't need to malloc the result at all.
> > > can fix this easily enough. However there appear to be more leaks in
> > True. I tried without malloc and it works fine. However, the leak is
> > still there. There is something else wrong.
> The code in ldap_int_sasl_bind() to free the prompts was hopeless because it
> only examined the first prompts structure, but usually SASL gives an array of
> prompts. It is too clumsy to try to manage this in libldap, especially given
> the possibility of different libraries using different malloc()s, so I have
> ripped out that code.
> I have updated liblutil to manage results more thoroughly, and added a
> lutil_sasl_freedefs() function to cleanup after the SASL bind completes.
> Please use this new design as a model for your own code.
Thanks. This makes more sense. However, there is still a leak and this
time it is in DIGEST-MD5. I tried PLAIN and CRAM-MD5 and it works fine
with those. I am going to try to profile DIGEST-MD5 plugin and see what
I want to be able to call ldap_sasl_interactive_bind_s() multiple times
without having to ldap_unbind() and then ldap_init(ialize)(). Is it
designed not to work this way or am I missing something?