Re: spamass-milter - solaris vs redhat

[Dan Nelson]

In the last episode (Jun 16), Chuck Yerkes said:
> I've been having these problems with S.A.M. at a solaris 8 site
> (compiled with gcc 2.95.3).
> 
> I've been debugging a bit on and off.  We've had problems. 500 users
> (for now), 8000 as a goal.  But we're having these problems.
> 
> With the watchmalloc stuff, the load on a 4x4 E450 (CPU x RAM) shoots
> up.
> 
> I've got some logging from Dan to try, but watchmalloc stuff seems to
> be cleaning up (hiding?) the problem.  But the load is too high.

Watchmalloc with MALLOC_DEBUG unset should only be slightly slower than
regular malloc.  You can also try linking with dmalloc 
( http://www.dmalloc.com ), which can be configured to report memory
leaks at program exit.
 
> We're likely going to TRY a linux box (over some objections cause
> Solaris as very strong support available here right now where linux
> might, later).
> 
> There's some string leak, I'm sure.  I'm stopping 8 bit mail from
> passing through (just in case).  I just don't know/trust the gcc++
> string routines well enough.  What happens when a body has a \0 in
> it? Does free() do the right thing?

Free works on malloc blocks, not strings, so it should do fine.  the
C++ string type has a length element so nulls won't affect it.  I'm
pretty sure that none of spamass-milter's string <-> char* conversions
leak memory.

> Hannu Liljemark wrote:
> > Anyways, there seems to be discussion about message corruption
> > in Solaris and other weird situations. I don't think we've
> > had that problem - at least users haven't reported anything
> > - but another problem seems to be spamass-milter process
> > crashing, and getting bloated over time:
> > 
> > % 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.  dmalloc would be good to try
here, since it should help narrow down what kind of data is leaking.

-- 
        Dan Nelson
        address@hidden