Re: spamass-milter - solaris vs redhat

[Chuck Yerkes]

I've stopped the sendmail listener for a few minutes, let the
processes die out and finish (previous hop is a local DMZ machine).
This gets the (solaris 8) machine quiet.

Then I've run "gcore" to get a dump of spamass-milter.
"strings" against it shows lots of mail data in the memory space.

I'm not sure if this is expected or not.  I'd EXPECT that when
the process is finished and all the threads are done, that the
string buffers would be "free()d" and no longer part of the
program's core.

OTOH, it could just be a residual part of the program being efficient
by reusing memory.  I don't know (I *do* know that perl is terrible
at actually giving up memory when it's done - it only grows).

So it's either normal behavior - keep space in process and reuse
it until program end - or it's an indication of a leak.

sigh.

Quoting Hannu Liljemark (address@hidden):
> > > % ps -eo user,pid,rss,vsz,nice,nlwp,etime,args|grep spamass-milter
> > > spamd 25796 57112 68560 20    6  1-02:07:14 
> > > /opt/spamass-milter/sbin/spamass-milter -p 
> > > /var/spool/spamassassin/spamass.sock
> > > 
> > > That had been running for a days (spamass-milter 0.1.3a).
> 
> > That's definitely huge.  What version of sendmail are you running? 
> > libmilter could be the source for your leaks.  8.12.2 fixed a
> > "theoretical memory leak", at least.
> 
> [The message should've said it had been running for a few days,
> but then again the leaking seems completely random.]
> 
> sendmail 8.12.9, compiled with the same gcc 2.95.3 as the
> spamass-milter. I think the normal sendmail 'sh Build install'
> stuff replaces Solaris' bundled sendmail libs, so it shouldn't
> be anything crazy like old .a files getting linked to the
> spamass-milter. I'll check. Strange if no one else has this :-)