Segmentation fault while loading local database

[Kyther]

I'm using the snap version on Linux Mint 18.1, installed about a week ago.

When I launch ElectronMail, it loads the "loading local database" screen. I have it set to automatically log in, so it attempts to do that, says it's loading the local database which can take up to 300 seconds… and then it segfaults. Every time. It worked the first few times, and I haven't done anything different or unusual that I can think of. No new accounts, etc. The last time I closed it it had the usual error I get when it's had some issue with the database, with 25000 ms timeout, but I've had that one before and it didn't crash the program. I can't remember what the exact words of that error were, unfortunately.

Launching it from terminal, this is what I get:

(node:20692) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(node:20692) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
(node:20692) DeprecationWarning: file property is deprecated and will be removed in v5.
(node:20692) DeprecationWarning: file property is deprecated and will be removed in v5.
(node:20692) ProtocolDeprecateCallback: The callback argument of protocol module APIs is no longer needed.
(node:20692) ProtocolDeprecateCallback: The callback argument of protocol module APIs is no longer needed.
.
.
.
(node:20692) ProtocolDeprecateCallback: The callback argument of protocol module APIs is no longer needed.


<--- Last few GCs --->
ca[20428:0x180400000000]     9590 ms: Mark-sweep 1023.6 (1026.1) -> 1023.4 (1026.6) MB, 99.4 / 0.1 ms  (+ 0.0 ms in 7 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 100 ms) (average mu = 0.196, current mu = 0.009) allocat[20428:0x180400000000]     9726 ms: Mark-sweep 1024.0 (1026.6) -> 1023.9 (1026.9) MB, 133.9 / 0.1 ms  (+ 0.0 ms in 7 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 135 ms) (average mu = 0.100, current mu = 0.011) alloca

<--- JS stacktrace --->
Segmentation fault

And the program's gone.

Note there's about a couple dozen lines of the ProtocolDeprecateCallback bit (I put the . . . vertically where they come in, as they're all identical) but that doesn't seem to really be the problem.

How do I get this to work again?

[vladimiry]

It looks like out of memory crash (like #110 and #277). I guess you got a lot of emails in your account. Can you try starting the app with --js-flags="--max-old-space-size=5120" command line argument (it sets the mem limit to 5120MB/5GB)? If it helps you might want to embed that CLI arg to the app shortcut for convenience. Unfortunately currently there is no convenient way to override the default nodejs's "max-old-space-size" value (the upstream/Electron issue has been placed).

[Kyther]

That did the trick. Thanks for the fix! I've added that to the shortcuts I use so it'll automatically execute that argument each time.

Yes, I have multiple accounts with far too many emails (some with large numbers of very small emails in them). I turned off local storage for several of the worst offenders just now and am hoping that will keep them from getting out of control. I'm planning on doing some more aggressive downloading and deleting of emails at some point, but I've had other projects take priority. I'm hoping to get those done before they get too much again! (I'm also hoping that turning off local storage for an account actually deletes all the email data stored on the hdd for that account? The local storage seemed to save all emails, even ones that had been later deleted on the account itself, so if it functioned thus, that would be a way of forcing a proper re-sync if desired…)

[vladimiry]

I'm also hoping that turning off local storage for an account actually deletes all the email data stored on the hdd for that account?

If you turning off the local storage flag for the account then the respective records get removed from the local database on the next app start, not immediately. So while the app is still running you have a chance to turn it back on without a need to re-sync the stuff since data is still in the memory.

I'm hoping to get those done before they get too much again!

You can then increase that mem limit even more :)

Hope the upstream/Electron issue gets resolved and so I could increase the default mem limit for everyone (the default value is ~2GB).

Closing the issue as resolved with a workaround.