[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: ldap_sasl_interactive_bind_s leaks? (ITS#2423)

On Sat, 5 Apr 2003, Howard Chu wrote:

> > -----Original Message-----
> > From: Igor Brezac [mailto:igor@ipass.net]
> > 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.
> We
> > > can fix this easily enough. However there appear to be more leaks in
> Cyrus
> >
> > 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?