[tpop3d-discuss] Tpop 1.4.2 memory leak?: fork_child: fork: Not enough space

[Chris Lightfoot]

On Thu, Jan 09, 2003 at 01:04:01PM -0800, Rich, WhidbeyNet NOC wrote:
> 
> We've been using PAM, so I ran the pamtest.c (gcc -lpam -o pamtest
> pamtest.c) for an hour on a test Solaris 9 machine. "vmstat" and
> "/usr/ucb/ps" showed that the "pamtest" process consumed an average of
> 15 Kb of memory per second, about 1 Mb/minute. After an hour, it was
> using 60mb of memory, and continued to grow.
> 
> The memory was released back to the system when the process was killed.
> If left to continue, would that steady consumption of memory by
> "pamtest" constitute a memory leak in pam?

My understanding is that pamtest.c is a correct PAM
program which should not leak memory, and that if it does
so, that indicates a leak in PAM.

Cf. also

    http://groups.google.com/groups?q=solaris+pam+memory+leak&hl=en&lr=&ie=UTF-8&selm=3vsoaxi963.fsf%40ratbert.iconnet.net&rnum=1

-- this is a real pain in the arse. I think that some
Linux PAM implementations are now leak-free, but the basic
issue is that the PAM developers didn't expect their code
to be used this way and so didn't make the effort. Typical
applications use PAM after fork()ing, but tpop3d isn't
built that way. I suppose it's possible that I could fork
a special process to do each PAM authentication, but
that's *really* ugly. Yuk.

> For now, I think we may disable pam and try "auth-passwd", to see if
> that helps.

That may well do. If you're going to move to LDAP, that
may be a sensible move.

> Are the changes in the CVS (1.5x) stable and significant
> enough to put in place of our 1.4.2?

Not yet stable, I'm afraid, though I believe others are
running it without trouble.

> Do the attached files shed any
> light?

Not tremendously-- a useful statistic to discover would be
the number of bytes leaked per authentication. That's easy
to compare against pamtest.c

-- 
``What would you call the creation of the universe?''
``The Horrendous Space Kablooie!''
  (Calvin and Hobbes)