Whenever I opened the Mailspring, it quickly uses all memory of the computer.
Image: https://imgur.com/a/yZ3PY
Ubuntu 16.10 x86_64
Bug?
No.
No, I'm using one Gmail account and one local mail.
I tried to remove each email but the problem still happened.
Feature Request?
No.
Thanks for filing this! We had one person mention this in a support email on Mac OS X yesterday as well. I haven't been able to track down the root cause yet but I'll keep you posted. It seems to happen rarely and be specific to an email inbox but that's the only lead I've got so far...
Hi @bengotow,
I noticed that the issue only happened when the Mailspring trying to sync the inbox.
Hope this help.
Thanks
Hello,
I also have this issue since upgrading to 1.0.3 on Ubuntu 17.04.
Yes, can confirm - Gentoo, downloaded latest 1.0.3 rpm available today. Mailsync process is capable of eating up 16G RAM + 16G swap in an instant, bringing the machine to a grinding halt.
@bengotow I saw your message on #131, if this info still is of any help I actually experienced the same issue with an imap account. The mailsync.bin process for that account will just hog up cpu and allocate all the memory it can find. With the account removed and the mailsync process killed all is well again.
I dug into the mailsync logs and found this:
17169 [2017-10-11 22:32:38.961] [main] [info] ------------- Starting Sync ---------------
17169 [2017-10-11 22:32:38.965] [metadata] [info] Metadata delta stream starting...
17169 [2017-10-11 22:32:38.966] [background] [info] Marking all folders as "busy`
17169 [2017-10-11 22:32:38.968] [background] [info] Syncing folder list...
17169 [2017-10-11 22:32:39.298] [background] [info] Syncing folder list...
17169 [2017-10-11 22:32:39.336] [background] [info] syncFolderChangesViaCondstore - INBOX: highestmodseq changed, requesting changes...
17169 [2017-10-11 22:32:39.552] [foreground] [info] Idling on folder INBOX
17169 [2017-10-11 22:32:58.911] [metadataExpiration] [info] Scanning for expired metadata
17169 [2017-10-11 22:32:58.911] [metadataExpiration] [info] -- Will wake for next expiration in 7201sec
16957 [2017-10-11 22:33:02.409] [background] [critical]
***
*** A C++ exception occurred during program execution:
*** std::bad_alloc
***
16957 [2017-10-11 22:33:02.514] [background] [critical] *** Stack trace (line numbers are approximate):
*** (unknown) clone
***
17169 [2017-10-11 22:33:32.891] [background] [critical]
***
*** A C++ exception occurred during program execution:
*** std::bad_alloc
***
17169 [2017-10-11 22:33:32.909] [background] [critical] *** Stack trace (line numbers are approximate):
*** (unknown) clone
***
17580 [2017-10-11 22:34:29.384] [main] [info] ------------- Starting Sync
And so on...
The account is an imap account with ssl, imap on port 994 and smtp on port 465. Allow insecure is disabled, as the server has a correct ssl certificate.
I'm running mailsync on archlinux, built from AUR
Same problem. Never ending "Syncing your mailbox..." and extremely high resource consumption.
Version 1.0.3. On the screenshot is comparison of consumption with Geary (same accounts)

I should have taken a screenshot before... but I experienced excessive memory use as well.
Running OSX 10.12.6.
Mailspring 1.0.3. No addons.
The mailsync process showed it using about 22GB+ memory. Installed Mailspring ~12 hrs prior.
EDIT: Just restarted, and within minutes, mailsync went to 100%CPU and this:

And already up to ~20GB~ 26.5GB in the time it took to insert that image.
Major memory leak with 1.0.4. I have 32 GB installed and with no apps open, it idles around 28 GB. When I open Mailspring, this will quickly go down to a crawling 900MB.
Hey folks—thanks for the follow-up. I haven't been able to reproduce this yet in any of my test accounts. If you have an account that doesn't contain anything valuable and would be willing to share it with me, we can probably get this fixed faster! (Feel free to email me at [email protected]) Unfortunately memory issues are tricky to track down with metrics and logging. In the couple of sync logs I've reviewed from users reporting this, there hasn't been anything odd. My guess is that a single bad message or bad server response can cause this, because it seems to just suddenly ask for all available memory.
I've got a couple new test accounts that are subscribed to a zillion linux mailing lists, and I'm hoping that'll make things like this easier to spot. (More email = more problems? hah.)
I have run into this issue as well. It occurred this morning after having to hard reboot my computer. I'm running Windows 10 x64 and Mailspring 1.0.4. mailsync had managed to eat all 32GB of my RAM within a fairly short amount of time. It seemed to be a bunch of mailsync processes using reasonable amounts, rather than a single huge process. It was also displaying error messages about being unable to sync my accounts. I have 4 accounts, and the total volume since last sync was probably somewhere around ~100 messages. Here's a redacted version of my mailsync.log (ignore unicode errors, that happened during redaction): https://gist.github.com/ShaBren/f38ff8bfe078ca9b8a9011b302e390b5
@bengotow Memory leak issue fixed in 1.0.5 (2a95f8f7). Thx!
on macOS still having issues.
While 2a95f8f still look like an improvement, mailsync still uses an awful lot of memory

and by the time I've screen captured and posted this, swap jumped to 16.48GB.
So I wouldn't consider this as 100% fixed
EDIT
had to post this edit as not more than 2 minutes later, memory usage spiked again (and still rising) to finally make my system run out of memory. So had to kill the processes.

Spoke to quickly... Memory leak still an issue with 1.0.5.
I have the same issue.
I've run mailsync under valgrind tools memcheck and massif. Logs are attached. I hope it will help.
I had this issue, too. (Both on Ubuntu 17.04 and 17.10, I started using Mailspring with 1.0.3 and it persisted through all versions). I believe that some of the reports in #158 describe the same issue (although they seem to be different, unrelated reports in #158).
I just removed the ~/.config/Mailspring folder and set up Mailspring from the ground up. Everything is fine now.
However, this issue only seems to appear in exceptional cases. I was never able to reproduce it with another account on the same server, even after copying in all my Emails. So the fact that I do not see it anymore doesn’t necessarily mean that the issue is fixed.
Talked too fast, I am sorry. The issue is back again.
Mailsync eats all RAM until it crashes with
20496 [2017-10-24 12:23:51.776] [background] [critical]
***
*** A C++ exception occurred during program execution:
*** std::bad_alloc
***
Excerpt from the repetitive Log
20458 [2017-10-24 12:22:43.890] [main] [info] ------------- Starting Sync (<mail address>) ---------------
20458 [2017-10-24 12:22:43.895] [background] [info] Marking all folders as `busy`
20458 [2017-10-24 12:22:43.896] [metadata] [info] Metadata delta stream starting...
20458 [2017-10-24 12:22:43.904] [background] [info] Syncing folder list...
20458 [2017-10-24 12:22:44.217] [background] [info] Syncing folder list...
20458 [2017-10-24 12:22:44.276] [background] [info] syncFolderChangesViaCondstore - INBOX: highestmodseq changed, requesting changes...
20458 [2017-10-24 12:22:44.506] [foreground] [info] Idling on folder INBOX
20458 [2017-10-24 12:22:58.899] [metadataExpiration] [info] Scanning for expired metadata
20458 [2017-10-24 12:22:58.899] [metadataExpiration] [info] -- Will wake for next expiration in 7201sec
20458 [2017-10-24 12:23:18.014] [background] [critical]
***
*** A C++ exception occurred during program execution:
*** std::bad_alloc
***
20458 [2017-10-24 12:23:18.039] [background] [critical] *** Stack trace (line numbers are approximate):
*** (unknown) clone
***
20496 [2017-10-24 12:23:18.301] [main] [info] ------------- Starting Sync (<mail address>) ---------------
20496 [2017-10-24 12:23:18.305] [background] [info] Marking all folders as `busy`
20496 [2017-10-24 12:23:18.308] [metadata] [info] Metadata delta stream starting...
20496 [2017-10-24 12:23:18.315] [background] [info] Syncing folder list...
20496 [2017-10-24 12:23:18.635] [background] [info] Syncing folder list...
20496 [2017-10-24 12:23:18.695] [background] [info] syncFolderChangesViaCondstore - INBOX: highestmodseq changed, requesting changes...
20496 [2017-10-24 12:23:18.928] [foreground] [info] Idling on folder INBOX
20496 [2017-10-24 12:23:33.306] [metadataExpiration] [info] Scanning for expired metadata
20496 [2017-10-24 12:23:33.306] [metadataExpiration] [info] -- Will wake for next expiration in 7201sec
20496 [2017-10-24 12:23:45.284] [foreground] [info] Idle exited with code 0
20496 [2017-10-24 12:23:45.285] [foreground] [info] Idling on folder INBOX
20496 [2017-10-24 12:23:51.776] [background] [critical]
***
*** A C++ exception occurred during program execution:
*** std::bad_alloc
***
20496 [2017-10-24 12:23:51.797] [background] [critical] *** Stack trace (line numbers are approximate):
*** (unknown) clone
***
… and so on …
I've not been able to recreate this issue with other accounts (same server, same config) and unfortunately the account with the issues is personal and I'm not able to share this account for testing.
Hey folks! @bynicolas installed the Xcode tools and sent me Instruments memory reports that allowed me to narrow this down. Essentially, Mailspring was asking the mail provider for a "list of messages deleted since time X", and it turns out that it's perfectly valid for the server to respond "messages 1121 to infinity" rather than with the typical format, which looks more like "1121, 1122, 1128", etc. Mailspring was trying to convert "[1121-infinity]" into a finite set of UIDs and immediately grabbing all the memory on the machine.
Thanks to everyone for reporting this and especially @bynicolas for the extensive debugging and testing. This should be fixed in the next release 👍
This issue was fixed for me by v1.0.7 (did not occur for more than 6 hours)
It seems the issue was fixed in v1.0.7.
Please help to close this issue.
Thanks @bengotow :)
So far so good! Thanks for the fix @bengotow
On Ubuntu 18.04, I have only 4GB memory, mailspring has take more than 500MB.

On Ubuntu 18.04, I have only 4GB memory, mailspring has take more than 500MB.
Any fix on this yet? I also have limited RAM, and mailspring eats it like crackers.
Best regards.
I heve the same problem on Linux Mint 19.3 (32 Go Ram +Swap 16 Go) fully taken by Mailspring processes, making my machine very slow and impossible to manage. When it's possible, I can solve it in terminal with "killall mailspring"
Therefore it's impossible for me to say more. But in journal, I have :
systemd-coredum
Process 5951 (main) of user 1000 dumped core.
Stack trace of thread 5972:
Stack trace of thread 5951:
Stack trace of thread 5958:
Stack trace of thread 5998:
Stack trace of thread 5962:
Stack trace of thread 5974:
AND
Process 5946 (main) of user 1000 dumped core.
Stack trace of thread 5969:
Stack trace of thread 5946:
Stack trace of thread 5957:
Stack trace of thread 5963:
Stack trace of thread 6030:
Stack trace of thread 5975:
Stack trace of thread 5965:
maybe mailsync.bin is the main cause of the problem.
Most helpful comment
Hey folks! @bynicolas installed the Xcode tools and sent me Instruments memory reports that allowed me to narrow this down. Essentially, Mailspring was asking the mail provider for a "list of messages deleted since time X", and it turns out that it's perfectly valid for the server to respond "messages 1121 to infinity" rather than with the typical format, which looks more like "1121, 1122, 1128", etc. Mailspring was trying to convert "[1121-infinity]" into a finite set of UIDs and immediately grabbing all the memory on the machine.
Thanks to everyone for reporting this and especially @bynicolas for the extensive debugging and testing. This should be fixed in the next release 👍