[tpop3d-discuss] Memory leak?

[Marc Lewis]

Tried both the auth_pam and the auth_ldap.  Both exhibit the leak.

One other thing that I've noticed is that authenticating from PAM leaks
memory much, much faster than with LDAP.

Authenticating from LDAP directly is slightly quicker, and doesn't leak as
quickly, but we get a lot of bad authentications -- a few hundred over a
four hour period.  The authentications are actually good, when they try
again it works.  Looks like there may be a timeout that is too short in the
ldap_simple_bind_s call when binding as the user.

Looking at this code, though, I think I may have stumbled on something
else related to the leak.

If an authentication fails, or anything falls outside of the loop, I see
several "goto fail;" lines, but looking at the code, some of the memory is
freed before the fail label, and only a small handful of things are freed
after failing.  I would need to study this a bit more before jumping to any
conclusions, but perhaps this is the source of the leak?  

Has anyone ever run the code through purify?

I haven't looked through the PAM code yet...

 - Marc

On Thu, May 09, 2002 at 01:50:20PM +0200, prune wrote:
> Hi,
> 
> did you try to use the auth_pam module built-in tpop3D ?
> this should be faster than PAM, indeed.
> It can be configured as you configured PAM.
> 
> maybe this can help you..
> 
> Cheers,
> 
> Prune
> 
> Marc Lewis wrote:
> 
> >On Wed, May 08, 2002 at 11:20:07PM +0100, Chris Lightfoot wrote:
> >
> >>On Wed, May 08, 2002 at 03:04:42PM -0700, Marc Lewis wrote:
> >>
> >[snip]
> >
> >>>Well, its better, but its still leaking a bit:
> >>>
> >>>root     10829  0.0  0.2  5196 2312 pts/1    S    12:18   0:05 /usr/src/tpop3d-1.4.1/tpop3d -f /etc/tpop3d-test.conf -d -v
> >>>
> >>>I have an expect script pounding on it generating about 20-30
> >>>authentications per minute for the last 30 minutes or so.
> >>>
> >>OK. I'll need to look into this one.
> >>
> >
> >I'm happy to run any patches or anything that you like on it.
> >
> >>>>>I know this is hackish sounding, but what is the motivation for doing all
> >>>>>of the auth and such before forking?  When I've written simple daemons and
> >>>>>
> >>    [...]
> >>
> >>>That makes perfect sense to me, but since the main server doesn't seem to
> >>>maintain a persistant connection to the authentication source (at least in
> >>>LDAP), the overhead of binding to the server per authentication still seems
> >>>to be there.  Not criticizing, just trying to understand.
> >>>
> >>Yeah-- it's not a problem with LDAP. I can't see myself
> >>rewriting it to be an inetd-style server, though.
> >>
> >>I may add an option to have it restart itself every so
> >>often.
> >>
> >
> >After looking through the code a bit more, I can see the hesitation in
> >making this an option.  Would require major reworking.
> >
> >
> >>>In thinking about this, it is possible that it is a problem in the OpenLDAP
> >>>libraries.  In my first build of tpop3d, I only configured in Maildir and
> >>>PAM support.  Since we are using PAM to access LDAP, its possible the leak
> >>>was caused by PAM's accesses to the LDAP server, since the program never
> >>>exited, things kept growing, but because of access to libpam.  Building
> >>>against LDAP directly lessons the leak, but it does definatly appear to
> >>>still be there.  Others using different non-LDAP authentication methods do
> >>>not appear to have these leaks.  Hmmm.
> >>>
> >>Which version of the OpenLDAP libraries are you using?
> >>
> >
> >v2.0.21-1 from RedHat 7.2 installation, then updates.
> >
> 

-- 
Marc Lewis
Network Administrator
Blarg! Online Services, Inc.
http://www.blarg.net/~marc