Re: [tpop3d-discuss] Memory leak?

[Chris Lightfoot]

On Wed, May 08, 2002 at 03:04:42PM -0700, Marc Lewis wrote:
> On Wed, May 08, 2002 at 09:32:46PM +0100, Chris Lightfoot wrote:
> > On Wed, May 08, 2002 at 01:07:34PM -0700, Marc Lewis wrote:
> > > On Wed, May 08, 2002 at 06:38:07PM +0100, Chris Lightfoot wrote:
> > > > On Wed, May 08, 2002 at 10:12:52AM -0700, Marc Lewis wrote:
> > > > > On Wed, May 08, 2002 at 11:40:56AM +0100, Chris Lightfoot wrote:
> >     [...]
> > > I've been running some tests using the auth-ldap module, and it appears
> > > that the leak is still there.
> > > 
> > > When first starting up the daemon:
> > > 
> > > root     10829  0.0  0.1  4788 1900 pts/1    S    12:18   0:00 
> > > /usr/src/tpop3d-1.4.1/tpop3d -f /etc/tpop3d-test.conf -d -v
> > > 
> > > After about a hundred or so mail checks (on a different port):
> > > 
> > > root     10829  0.0  0.1  4836 1948 pts/1    S    12:18   0:00 
> > > /usr/src/tpop3d-1.4.1/tpop3d -f /etc/tpop3d-test.conf -d -v
> > > 
> > > Looks like it has grown by about 48K.  So, it appears to be a small leak,
> > > but there none the less.
> > 
> > Errm. I'd want to run the test for a bit longer than that
> > to be sure-- a change of 48k could just be `noise'. How
> > much does it grow after a few thousand checks?
> 
> 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 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.

> 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?

> [snip]
> > Yep. I did some work on a Postgres-based solution for this
> > (to me, LDAP looks more like a buzzword than a solution,
> > but I imagine this puts me in a minority...).
> [snip]
> 
> The one advantage that I have found in using LDAP over anything else is not
> an elegant design, or good documentation, or anything else nice like that.
> The advantage is that it is central and secure and everything supports it.
> The problem with SQL based solutions is that everyone has their own
> implementation and database schemas, with LDAP things are pretty strictly
> laid out.

Makes sense, I guess....

-- 
``... Now I had improved the program to the point
  where it would not work at all.'' (George Greenstein, from `Frozen Star')