Re: [tpop3d-discuss] Memory leak?

[Chris Lightfoot]

On Fri, May 10, 2002 at 12:06:45PM -0700, Marc Lewis wrote:
> On Fri, May 10, 2002 at 07:19:00PM +0100, Chris Lightfoot wrote:
> > On Fri, May 10, 2002 at 11:12:28AM -0700, Marc Lewis wrote:
> > > On Thu, May 09, 2002 at 11:36:00PM +0100, Chris Lightfoot wrote:
    [...]
> > > This patch, against your patched auth_ldap.c, fixed it for me.  Its
> > > probably the totally wrong way to do it, but I beat the snot out of it 
> > > with
> > > multiple expect scripts doing nothing but logging in and logging out for 
> > > 30
> > > minutes, generating between 100 and 150 connections per minute, and had 
> > > not
> > > a single failure to authenticate.  There were quite a few ldap timeouts,
> > > but it retries and succeeds on the second try.  Not sure why, but it looks
> > > like it needs this on our system.
> > 
> > How bizarre. I see that you've put both the call to
> > ldap_search_s and to ldap_simple_bind_s in loops -- is the
> > latter necessary? Perhaps I should alter the code so that
> > all calls to the ldap library are attempted multiple
> > times?
> 
> The failures were varying in location.  After your patch, all of the errors
> ended up in the ldap_simple_bind_s when binding as the user, which really
> bothered me because logically they should not have been there.

Agree.

> > Did you try your patch without reconnecting to the LDAP
> > server on each authentication?
> 
> I believe so...No wait, I must have -- I split them out into two different
> files.
> 
> Before the reconnect patch, it would fail in the search and the bind calls.
> After your patch, they all ended up in the simple_bind_s.

Goodness. Bizarre.

> 64.  The purpose of mentioning all of this is that I don't think that it is
> necessarily tpop3d that is having the problem, but the way that OpenLDAP
> handles connections on a busy server.  I haven't looked at the source for
> the other modules from padl.com to see if they also have loops in their
> bind or how they handle retry issues, I just know they haven't ever failed
> like the direct ldap calls have been.

Could you give me urls for the PAM/NSS stuff? I would be
interested to see (a) whether they have loops; (b) whether
there are any obvious leaks in them. As I say, I believe
that the tpop3d PAM code is correct in the `free of leaks'
sense.

OOI, does the PAM module do bind-as-user or does it just
dig out the userpassword attribute and authenticate
against that?

> I'll be making this patched version live on our system later today, and
> will let you know if I run into issues.

OK. I will be interested to hear the results-- clearly I'm
going to need to fix the auth_ldap stuff, but it would be
nice to know exactly what's wrong.

-- 
I can't explain glacial motion/
Or why Los Angeles don't drop into the ocean
(`Naked And Famous', Presidents of the USA)