SAM: Re: spamass-milter - solaris vs redhat

[Chuck Yerkes]

Quoting Dan Nelson (address@hidden):
> 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.
For me load went from 0.11 to 7-8.

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

Yeah, I know.  I'm wondering if certain messages are triggering
chaos within the memory space.  By "leak" I was imprecise: I believe
that something in valid memory is being stepped on.  The "corruptions"
were seeing are clearly several messages glommed together.

Tried with both 8.12.9 and Sendmail Switch's MTA (8.12.9, but built
by the gang at Sendmail, Inc).

> > 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.
This is another message (hannu's) so I can't reply.