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

[Michal Suchánek]

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.

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/20181128/2a1a93d2/attachment.sig>