[Users] [Bug 4104] SMTP doesn't work over VPN

[Michal Suchánek]

On Wed, 28 Nov 2018 21:44:23 +0100
Michal Suchánek <msuchanek at suse.de> wrote:

> On Wed, 28 Nov 2018 21:24:11 +0100
> Andrej Kacian <ticho at claws-mail.org> wrote:
> 
> > On Wed, 28 Nov 2018 18:10:36 +0100
> > Michal Suchánek wrote:
> >   
> > > According to top it is claws using memory. It's the top offender. Also
> > > when I run claws it takes about 700M virtual/60M resident. When I
> > > open a small folder this does not change much. When I open inbox this
> > > grows to like 2G VSS/ 1G RSS, and when I open small folder again it
> > > does not get down. Opening inbox does not seem any faster the second
> > > time. So to me it looks like claws is hoarding large amounts of
> > > memory for no good reason (other than freeing it properly sounds like
> > > work).    
> > 
> > If only it was that simple. :) Besides Claws Mail data, VSS/RSS also
> > include any data and code objects from shared libraries (libc, glibc,
> > gtk+, ...). Those are loaded only when first needed, and not merely on
> > the application startup. That's why e.g. opening of a first folder
> > makes the memory footprint grow considerably more than opening of a
> > second folder, regardless of size of either, because for the second
> > opening operation, most of what's needed is already loaded in memory.  
> 
> And that's not the problem here. I specifically open a small folder
> first for comparison. After opening a big folder the occupied memory
> grows significantly and never drops.
> 
> >   
> > > Worse, fork()
> > > has to replicate the page tables for the process and it may run out of
> > > memory for said tables which depend solely on VSS size.    
> > 
> > The way I understand it, page tables themselves are not very big,
> > perhaps 1-2MB of kernel space
> > ("grep VmPTE /proc/$(pidof claws-mail)/status" for exact number at a
> > given moment). Content of those memory pages is another matter, but
> > that is not duplicated at the time of fork(). The memory pages are
> > duplicated and allocated for the child process only when parent of
> > child writes to them later (copy-on-write).
> > 
> > That's why I find it incredible that on any today's decent desktop
> > system, things could go as far as fork() reporting ENOMEM.  
> 
> Processes grow until they occupy all available memory. Plus this is on
> a laptop which is more a thin client than a decent machine. I suppose I
> could run claws on a remote machine to save memory at the expense of
> network bandwidth.
> 
> > 
> > There could also be leaks which are triggered over and over again. Just
> > a few months ago, we fixed a leak which IIRC leaked a few hundreds
> > of bytes on every POP3 mail fetch, along with a dozen or so other,
> > smaller leaks. What can I say, C is hard, and we make mistakes. :)
> > 
> > There are probably other uncaught leaks in the code, perhaps some
> > triggered only in conditions which I, or whoever bothers running Claws
> > Mail through valgrind or similar tool, do not happen to have, so they
> > go undetected, and after weeks of uptime, they inevitably add up.  
> 
> They add up by opening inbox for me. It should be quite easy to run
> through valgrind then I suppose.
> 

The inbox has around 400k messages in an IMAP folder.

valgrind does not find anything amiss (in claws itself, it did not
trace the workers). So it looks like there is something allocated by
claws on opening a folder that is properly freed on exit but not on
closing the folder. 

Thanks

Michal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.claws-mail.org/pipermail/users/attachments/20181203/4673bd6b/attachment.sig>