Mailspring: [Critical] Memory leak using all memory on computer

Created on 9 Oct 2017  Â·  24Comments  Â·  Source: Foundry376/Mailspring

Are there any related issues?


Whenever I opened the Mailspring, it quickly uses all memory of the computer.
Image: https://imgur.com/a/yZ3PY

What operating system are you using?

Ubuntu 16.10 x86_64

What version of Mailspring are you using?

1.0.2-4eab3f85

Bug?

Do you have any third-party plugins installed? If so, which ones?

No.

Is the issue related to a specific email provider (Gmail, Exchange, etc.)?

No, I'm using one Gmail account and one local mail.
I tried to remove each email but the problem still happened.

Is the issue reproducible with a particular attachment, message, signature, etc?

No, the issue happened whenever I started up the Mailspring.

Feature Request?

Does this feature exist in another mail client or tool you use?

No.

bug done-pending-release

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 👍

All 24 comments

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)

snapshot-2017-10-12-11-09-27-geary

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:
mailsync memory

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

mailsync memory usage

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.

mailsync memory usage 2

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.

valgrind13935.log
massif16809.log

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

On Ubuntu 18.04, I have only 4GB memory, mailspring has take more than 500MB.
image

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:

0 0x0000000000e02ba6 ERR_clear_error (mailsync.bin)

1 0x0000000000d77f07 ossl_recv (mailsync.bin)

2 0x0000000000d5aa8f Curl_read (mailsync.bin)

3 0x0000000000d63db9 Curl_readwrite (mailsync.bin)

4 0x0000000000d55a89 multi_runsingle (mailsync.bin)

5 0x0000000000d5650b curl_multi_perform (mailsync.bin)

6 0x0000000000d40523 curl_easy_perform (mailsync.bin)

7 0x00000000008c5483 _ZN14MetadataWorker19fetchDeltasBlockingEv (mailsync.bin)

8 0x00000000008c4850 _ZN14MetadataWorker3runEv (mailsync.bin)

9 0x00000000007d0267 _ZZ4mainENKUlvE3_clEv (mailsync.bin)

10 0x00000000007dd450 _ZNSt12_Bind_simpleIFZ4mainEUlvE3_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE (mailsync.bin)

11 0x00000000007dd16f _ZNSt12_Bind_simpleIFZ4mainEUlvE3_vEEclEv (mailsync.bin)

12 0x00000000007dceca _ZNSt6thread5_ImplISt12_Bind_simpleIFZ4mainEUlvE3_vEEE6_M_runEv (mailsync.bin)

13 0x0000000000f80360 execute_native_thread_routine (mailsync.bin)

14 0x00007ff45ee5c6db start_thread (libpthread.so.0)

15 0x00007ff45e3c8a3f __clone (libc.so.6)

Stack trace of thread 5951:

0 0x00007ff45ee62449 futex_wait (libpthread.so.0)

1 0x00007ff45e2ea0f1 __run_exit_handlers (libc.so.6)

2 0x00007ff45e2ea1ea __GI_exit (libc.so.6)

3 0x00000000007cf38b _Z21runListenOnMainThreadSt10shared_ptrI7AccountE (mailsync.bin)

4 0x00000000007d1835 main (mailsync.bin)

5 0x00007ff45e2c8b97 __libc_start_main (libc.so.6)

6 0x00000000007caa65 _start (mailsync.bin)

Stack trace of thread 5958:

0 0x00007ff45ee62f85 futex_abstimed_wait_cancelable (libpthread.so.0)

1 0x00000000007cac05 _ZL24__gthread_cond_timedwaitP14pthread_cond_tP15pthread_mutex_tPK8timespec (mailsync.bin)

2 0x00000000007f9375 _ZNSt18condition_variable17__wait_until_implINSt6chrono8durationIlSt5ratioILl1ELl1000000000EEEEEESt9cv_statusRSt11unique_lockISt5mutexERKNS1_10time_pointINS1_3_V212system_clockET_EE (mailsync.bin)

3 0x00000000007f122d _ZNSt18condition_variable10wait_untilINSt6chrono8durationIlSt5ratioILl1ELl1000000000EEEEEESt9cv_statusRSt11unique_lockISt5mutexERKNS1_10time_pointINS1_3_V212system_clockET_EE (mailsync.bin)

4 0x00000000007ccaf4 _Z12runFlushLoopv (mailsync.bin)

5 0x000000000083a191 _ZNSt12_Bind_simpleIFPFvvEvEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE (mailsync.bin)

6 0x0000000000839713 _ZNSt12_Bind_simpleIFPFvvEvEEclEv (mailsync.bin)

7 0x0000000000838e40 _ZNSt6thread5_ImplISt12_Bind_simpleIFPFvvEvEEE6_M_runEv (mailsync.bin)

8 0x0000000000f80360 execute_native_thread_routine (mailsync.bin)

9 0x00007ff45ee5c6db start_thread (libpthread.so.0)

10 0x00007ff45e3c8a3f __clone (libc.so.6)

Stack trace of thread 5998:

0 0x00007ff45ee629f3 futex_wait_cancelable (libpthread.so.0)

1 0x0000000000f80f3c _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE (mailsync.bin)

2 0x00000000008d6d8b _ZN10SyncWorker18idleCycleIterationEv (mailsync.bin)

3 0x00000000007ccea4 _Z23runForegroundSyncWorkerv (mailsync.bin)

4 0x00000000007cd15c _ZZ23runBackgroundSyncWorkervENKUlvE_clEv (mailsync.bin)

5 0x00000000007dd626 _ZNSt12_Bind_simpleIFZ23runBackgroundSyncWorkervEUlvE_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE (mailsync.bin)

6 0x00000000007dd223 _ZNSt12_Bind_simpleIFZ23runBackgroundSyncWorkervEUlvE_vEEclEv (mailsync.bin)

7 0x00000000007dcf6a _ZNSt6thread5_ImplISt12_Bind_simpleIFZ23runBackgroundSyncWorkervEUlvE_vEEE6_M_runEv (mailsync.bin)

8 0x0000000000f80360 execute_native_thread_routine (mailsync.bin)

9 0x00007ff45ee5c6db start_thread (libpthread.so.0)

10 0x00007ff45e3c8a3f __clone (libc.so.6)

Stack trace of thread 5962:

0 0x00007ff45ee62f85 futex_abstimed_wait_cancelable (libpthread.so.0)

1 0x00000000007cac05 _ZL24__gthread_cond_timedwaitP14pthread_cond_tP15pthread_mutex_tPK8timespec (mailsync.bin)

2 0x00000000007f9375 _ZNSt18condition_variable17__wait_until_implINSt6chrono8durationIlSt5ratioILl1ELl1000000000EEEEEESt9cv_statusRSt11unique_lockISt5mutexERKNS1_10time_pointINS1_3_V212system_clockET_EE (mailsync.bin)

3 0x00000000007f122d _ZNSt18condition_variable10wait_untilINSt6chrono8durationIlSt5ratioILl1ELl1000000000EEEEEESt9cv_statusRSt11unique_lockISt5mutexERKNS1_10time_pointINS1_3_V212system_clockET_EE (mailsync.bin)

4 0x00000000008af92c _ZN9MailUtils25sleepWorkerUntilWakeOrSecEi (mailsync.bin)

5 0x00000000007cd36f _Z23runBackgroundSyncWorkerv (mailsync.bin)

6 0x00000000007d011e _ZZ4mainENKUlvE1_clEv (mailsync.bin)

7 0x00000000007dd50c _ZNSt12_Bind_simpleIFZ4mainEUlvE1_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE (mailsync.bin)

8 0x00000000007dd1b7 _ZNSt12_Bind_simpleIFZ4mainEUlvE1_vEEclEv (mailsync.bin)

9 0x00000000007dcf0a _ZNSt6thread5_ImplISt12_Bind_simpleIFZ4mainEUlvE1_vEEE6_M_runEv (mailsync.bin)

10 0x0000000000f80360 execute_native_thread_routine (mailsync.bin)

11 0x00007ff45ee5c6db start_thread (libpthread.so.0)

12 0x00007ff45e3c8a3f __clone (libc.so.6)

Stack trace of thread 5974:

0 0x00007ff45ee62f85 futex_abstimed_wait_cancelable (libpthread.so.0)

1 0x00000000007cac05 _ZL24__gthread_cond_timedwaitP14pthread_cond_tP15pthread_mutex_tPK8timespec (mailsync.bin)

2 0x00000000007f9375 _ZNSt18condition_variable17__wait_until_implINSt6chrono8durationIlSt5ratioILl1ELl1000000000EEEEEESt9cv_statusRSt11unique_lockISt5mutexERKNS1_10time_pointINS1_3_V212system_clockET_EE (mailsync.bin)

3 0x00000000007f122d _ZNSt18condition_variable10wait_untilINSt6chrono8durationIlSt5ratioILl1ELl1000000000EEEEEESt9cv_statusRSt11unique_lockISt5mutexERKNS1_10time_pointINS1_3_V212system_clockET_EE (mailsync.bin)

4 0x00000000008bf542 _ZN24MetadataExpirationWorker3runEv (mailsync.bin)

5 0x00000000007d02f0 _ZZ4mainENKUlvE4_clEv (mailsync.bin)

6 0x00000000007dd3f2 _ZNSt12_Bind_simpleIFZ4mainEUlvE4_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE (mailsync.bin)

7 0x00000000007dd14b _ZNSt12_Bind_simpleIFZ4mainEUlvE4_vEEclEv (mailsync.bin)

8 0x00000000007dceaa _ZNSt6thread5_ImplISt12_Bind_simpleIFZ4mainEUlvE4_vEEE6_M_runEv (mailsync.bin)

9 0x0000000000f80360 execute_native_thread_routine (mailsync.bin)

10 0x00007ff45ee5c6db start_thread (libpthread.so.0)

11 0x00007ff45e3c8a3f __clone (libc.so.6)

AND

Process 5946 (main) of user 1000 dumped core.

Stack trace of thread 5969:

0 0x0000000000e02ba6 ERR_clear_error (mailsync.bin)

1 0x0000000000d77f07 ossl_recv (mailsync.bin)

2 0x0000000000d5aa8f Curl_read (mailsync.bin)

3 0x0000000000d63db9 Curl_readwrite (mailsync.bin)

4 0x0000000000d55a89 multi_runsingle (mailsync.bin)

5 0x0000000000d5650b curl_multi_perform (mailsync.bin)

6 0x0000000000d40523 curl_easy_perform (mailsync.bin)

7 0x00000000008c5483 _ZN14MetadataWorker19fetchDeltasBlockingEv (mailsync.bin)

8 0x00000000008c4850 _ZN14MetadataWorker3runEv (mailsync.bin)

9 0x00000000007d0267 _ZZ4mainENKUlvE3_clEv (mailsync.bin)

10 0x00000000007dd450 _ZNSt12_Bind_simpleIFZ4mainEUlvE3_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE (mailsync.bin)

11 0x00000000007dd16f _ZNSt12_Bind_simpleIFZ4mainEUlvE3_vEEclEv (mailsync.bin)

12 0x00000000007dceca _ZNSt6thread5_ImplISt12_Bind_simpleIFZ4mainEUlvE3_vEEE6_M_runEv (mailsync.bin)

13 0x0000000000f80360 execute_native_thread_routine (mailsync.bin)

14 0x00007f536e63d6db start_thread (libpthread.so.0)

15 0x00007f536dba9a3f __clone (libc.so.6)

Stack trace of thread 5946:

0 0x00007f536e643449 futex_wait (libpthread.so.0)

1 0x00007f536dacb0f1 __run_exit_handlers (libc.so.6)

2 0x00007f536dacb1ea __GI_exit (libc.so.6)

3 0x00000000007cf38b _Z21runListenOnMainThreadSt10shared_ptrI7AccountE (mailsync.bin)

4 0x00000000007d1835 main (mailsync.bin)

5 0x00007f536daa9b97 __libc_start_main (libc.so.6)

6 0x00000000007caa65 _start (mailsync.bin)

Stack trace of thread 5957:

0 0x00007f536e643f85 futex_abstimed_wait_cancelable (libpthread.so.0)

1 0x00000000007cac05 _ZL24__gthread_cond_timedwaitP14pthread_cond_tP15pthread_mutex_tPK8timespec (mailsync.bin)

2 0x00000000007f9375 _ZNSt18condition_variable17__wait_until_implINSt6chrono8durationIlSt5ratioILl1ELl1000000000EEEEEESt9cv_statusRSt11unique_lockISt5mutexERKNS1_10time_pointINS1_3_V212system_clockET_EE (mailsync.bin)

3 0x00000000007f122d _ZNSt18condition_variable10wait_untilINSt6chrono8durationIlSt5ratioILl1ELl1000000000EEEEEESt9cv_statusRSt11unique_lockISt5mutexERKNS1_10time_pointINS1_3_V212system_clockET_EE (mailsync.bin)

4 0x00000000007ccaf4 _Z12runFlushLoopv (mailsync.bin)

5 0x000000000083a191 _ZNSt12_Bind_simpleIFPFvvEvEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE (mailsync.bin)

6 0x0000000000839713 _ZNSt12_Bind_simpleIFPFvvEvEEclEv (mailsync.bin)

7 0x0000000000838e40 _ZNSt6thread5_ImplISt12_Bind_simpleIFPFvvEvEEE6_M_runEv (mailsync.bin)

8 0x0000000000f80360 execute_native_thread_routine (mailsync.bin)

9 0x00007f536e63d6db start_thread (libpthread.so.0)

10 0x00007f536dba9a3f __clone (libc.so.6)

Stack trace of thread 5963:

0 0x00007f536e643f85 futex_abstimed_wait_cancelable (libpthread.so.0)

1 0x00000000007cac05 _ZL24__gthread_cond_timedwaitP14pthread_cond_tP15pthread_mutex_tPK8timespec (mailsync.bin)

2 0x00000000007f9375 _ZNSt18condition_variable17__wait_until_implINSt6chrono8durationIlSt5ratioILl1ELl1000000000EEEEEESt9cv_statusRSt11unique_lockISt5mutexERKNS1_10time_pointINS1_3_V212system_clockET_EE (mailsync.bin)

3 0x00000000007f122d _ZNSt18condition_variable10wait_untilINSt6chrono8durationIlSt5ratioILl1ELl1000000000EEEEEESt9cv_statusRSt11unique_lockISt5mutexERKNS1_10time_pointINS1_3_V212system_clockET_EE (mailsync.bin)

4 0x00000000008af92c _ZN9MailUtils25sleepWorkerUntilWakeOrSecEi (mailsync.bin)

5 0x00000000007cd36f _Z23runBackgroundSyncWorkerv (mailsync.bin)

6 0x00000000007d011e _ZZ4mainENKUlvE1_clEv (mailsync.bin)

7 0x00000000007dd50c _ZNSt12_Bind_simpleIFZ4mainEUlvE1_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE (mailsync.bin)

8 0x00000000007dd1b7 _ZNSt12_Bind_simpleIFZ4mainEUlvE1_vEEclEv (mailsync.bin)

9 0x00000000007dcf0a _ZNSt6thread5_ImplISt12_Bind_simpleIFZ4mainEUlvE1_vEEE6_M_runEv (mailsync.bin)

10 0x0000000000f80360 execute_native_thread_routine (mailsync.bin)

11 0x00007f536e63d6db start_thread (libpthread.so.0)

12 0x00007f536dba9a3f __clone (libc.so.6)

Stack trace of thread 6030:

0 0x00007f536e6439f3 futex_wait_cancelable (libpthread.so.0)

1 0x0000000000f80f3c _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE (mailsync.bin)

2 0x00000000008d6d8b _ZN10SyncWorker18idleCycleIterationEv (mailsync.bin)

3 0x00000000007ccea4 _Z23runForegroundSyncWorkerv (mailsync.bin)

4 0x00000000007cd15c _ZZ23runBackgroundSyncWorkervENKUlvE_clEv (mailsync.bin)

5 0x00000000007dd626 _ZNSt12_Bind_simpleIFZ23runBackgroundSyncWorkervEUlvE_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE (mailsync.bin)

6 0x00000000007dd223 _ZNSt12_Bind_simpleIFZ23runBackgroundSyncWorkervEUlvE_vEEclEv (mailsync.bin)

7 0x00000000007dcf6a _ZNSt6thread5_ImplISt12_Bind_simpleIFZ23runBackgroundSyncWorkervEUlvE_vEEE6_M_runEv (mailsync.bin)

8 0x0000000000f80360 execute_native_thread_routine (mailsync.bin)

9 0x00007f536e63d6db start_thread (libpthread.so.0)

10 0x00007f536dba9a3f __clone (libc.so.6)

Stack trace of thread 5975:

0 0x00007f536e643f85 futex_abstimed_wait_cancelable (libpthread.so.0)

1 0x00000000007cac05 _ZL24__gthread_cond_timedwaitP14pthread_cond_tP15pthread_mutex_tPK8timespec (mailsync.bin)

2 0x00000000007f9375 _ZNSt18condition_variable17__wait_until_implINSt6chrono8durationIlSt5ratioILl1ELl1000000000EEEEEESt9cv_statusRSt11unique_lockISt5mutexERKNS1_10time_pointINS1_3_V212system_clockET_EE (mailsync.bin)

3 0x00000000007f122d _ZNSt18condition_variable10wait_untilINSt6chrono8durationIlSt5ratioILl1ELl1000000000EEEEEESt9cv_statusRSt11unique_lockISt5mutexERKNS1_10time_pointINS1_3_V212system_clockET_EE (mailsync.bin)

4 0x00000000008bf542 _ZN24MetadataExpirationWorker3runEv (mailsync.bin)

5 0x00000000007d02f0 _ZZ4mainENKUlvE4_clEv (mailsync.bin)

6 0x00000000007dd3f2 _ZNSt12_Bind_simpleIFZ4mainEUlvE4_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE (mailsync.bin)

7 0x00000000007dd14b _ZNSt12_Bind_simpleIFZ4mainEUlvE4_vEEclEv (mailsync.bin)

8 0x00000000007dceaa _ZNSt6thread5_ImplISt12_Bind_simpleIFZ4mainEUlvE4_vEEE6_M_runEv (mailsync.bin)

9 0x0000000000f80360 execute_native_thread_routine (mailsync.bin)

10 0x00007f536e63d6db start_thread (libpthread.so.0)

11 0x00007f536dba9a3f __clone (libc.so.6)

Stack trace of thread 5965:

0 0x00007f536e647c70 __GI___nanosleep (libpthread.so.0)

1 0x00000000007f1cd1 _ZNSt11this_thread9sleep_forIlSt5ratioILl60ELl1EEEEvRKNSt6chrono8durationIT_T0_EE (mailsync.bin)

2 0x00000000007cd66d _Z24runCalContactsSyncWorkerv (mailsync.bin)

3 0x00000000007d01e8 _ZZ4mainENKUlvE2_clEv (mailsync.bin)

4 0x00000000007dd4ae _ZNSt12_Bind_simpleIFZ4mainEUlvE2_vEE9_M_invokeIJEEEvSt12_Index_tupleIJXspT_EEE (mailsync.bin)

5 0x00000000007dd193 _ZNSt12_Bind_simpleIFZ4mainEUlvE2_vEEclEv (mailsync.bin)

6 0x00000000007dceea _ZNSt6thread5_ImplISt12_Bind_simpleIFZ4mainEUlvE2_vEEE6_M_runEv (mailsync.bin)

7 0x0000000000f80360 execute_native_thread_routine (mailsync.bin)

8 0x00007f536e63d6db start_thread (libpthread.so.0)

9 0x00007f536dba9a3f __clone (libc.so.6)

maybe mailsync.bin is the main cause of the problem.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

3v1n0 picture 3v1n0  Â·  3Comments

DanielRios549 picture DanielRios549  Â·  3Comments

scooby picture scooby  Â·  3Comments

LeandroStanger picture LeandroStanger  Â·  3Comments

vsanchez picture vsanchez  Â·  3Comments