Re: spamass-milter - solaris vs redhat

[Dan Nelson]

In the last episode (Jun 18), Chuck Yerkes said:
> 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.

Theoretically possible; most mallocs only free memory back to the OS
when it's at the end of the current address space:

                                         / brk() point
|   block1    |   block2   |   block3   |

If you free block2, nothing will happen.  If you free block3, malloc
will call brk() and pull the break point back to the end of block1,
returning both memory regions to the OS.
 
> 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.

There are a couple ways to tell the difference.  One way is to link
with a malloc that overwrites free'd memory.  Then any message bodies
you see in the corefile are leaked (assuming there were no messages in
flight when the core was made).

Another is to link with a malloc that tracks mallocs and frees, and can
print a list of leaked blocks at program exit.  Dmalloc can do this,
but the current release doesn't work due to a header bug.  Once 5.2.1
or greater is released, you can run configure --with-dmalloc to link it
into spamass-milter.

-- 
        Dan Nelson
        address@hidden