Mailspring 1.25.0 regression: mailsync SIGSEGV every 28 minutes

Sync Issues
1

Description

After upgrading to Mailspring 1.25.0, mailsync.bin repeatedly crashes with SIGSEGV during the IMAP IDLE refresh cycle.

The crash is highly reproducible and appears to be a regression from 1.24.1.

Mailspring itself remains usable because the sync processes are restarted automatically, but systemd records multiple core dumps.

Environment

  • Linux x86-64

  • Mailspring installed via Snap

  • Affected version: 1.25.0, Snap revision 626

  • Previous working version: 1.24.1, Snap revision 624

  • Multiple email accounts configured

  • Reproduced on more than one account

Crash

A representative core dump:

Signal: 11 (SEGV)

Command Line:
/snap/mailspring/626/usr/share/mailspring/resources/app.asar.unpacked/mailsync.bin --mode sync --info <account>

Stack trace:

#0 mailcore::IMAPSession::collectVanishedFromLastResponse()
   mailsync.bin + 0x444100

#1 mailcore::IMAPSession::takeVanishedMessages(mailcore::String*)
   mailsync.bin + 0x4442f0

#2 SyncWorker::idleCycleIteration()
   mailsync.bin + 0x269883

#3 runForegroundSyncWorker()

I checked several separate crashes and they all have the same top frames and the same offsets:

collectVanishedFromLastResponse() + 0x444100
takeVanishedMessages()           + 0x4442f0
SyncWorker::idleCycleIteration() + 0x269883

Reproduction pattern

The crashes occur almost exactly every 28 minutes.

Example:

20:37:20  SIGSEGV
21:05:24  SIGSEGV
21:33:28  SIGSEGV
22:01:32  SIGSEGV
22:29:36  SIGSEGV

For an individual account, the mailsync log shows:

20:37:22.809  Idling on folder INBOX
...
21:05:23.181  Idle exited with code 1
21:05:24.xxx  SIGSEGV

The crash then occurs inside:

idleCycleIteration()
  -> takeVanishedMessages()
  -> collectVanishedFromLastResponse()

Multiple accounts can crash during the same ~28 minute cycle.

Regression test

I reverted the Snap package from:

Mailspring 1.25.0 rev 626

to:

Mailspring 1.24.1 rev 624

and held the package at 1.24.1.

With 1.24.1 running for multiple IDLE cycles, there were no new coredumps.

For example, several accounts successfully completed repeated IDLE refresh cycles:

12:44  Idle exited with code 0
13:12  Idle exited with code 0
13:40  Idle exited with code 0

More importantly, some IMAP accounts still return:

Idle exited with code 1

on 1.24.1, but the same mailsync process survives and continues with the next IDLE cycle:

12:44  Idle exited with code 1
13:12  Idle exited with code 1
13:40  Idle exited with code 1

There were no SIGSEGVs after the downgrade.

This makes the A/B result:

1.25.0:
IDLE refresh
 -> Idle exited
 -> collectVanishedFromLastResponse()
 -> SIGSEGV

1.24.1:
IDLE refresh
 -> Idle exited
 -> continues normally

Expected behavior

The foreground sync worker should complete the periodic IMAP IDLE refresh without crashing, as it does in 1.24.1.

Additional observations

  • The UI itself does not crash.

  • Mail can still be opened and used because mailsync processes appear to restart after crashing.

  • Regular background folder synchronization works before the crash.

  • The issue is not isolated to a single account.

  • Downgrading only Mailspring from 1.25.0 to 1.24.1 eliminates the crashes without changing the accounts or server configuration.

I can provide additional coredumpctl output or mailsync logs if useful.

2

Seeing the same thing on arm64, so this doesn’t look arch-specific.

Setup: Mailspring 1.25.0 snap rev 625 on Fedora Asahi Remix 44 (aarch64, 16K page size). Affected account is IMAP on Soverin (Dovecot with CONDSTORE/QRESYNC). A Gmail account on the same install never crashes, its worker stays up for days.

Frequency: every few days rather than every 28 minutes, on the same 1.25.0.

Today’s crash from mailsync log and coredumpctl:
62695 [2026-09-23 08:48:23.534] [background] [info] Sync loop complete.
— SIGSEGV at 08:49:19 —
99971 [2026-09-23 08:49:19.975] [main] [info] ------------- Starting Sync (contact@[redacted]) ---------------

Stack looks similar to yours:
#0 mailcore::IMAPSession::collectVanishedFromLastResponse() (mailsync.bin + 0x43ad1c)
#1 mailcore::IMAPSession::takeVanishedMessages(mailcore::String*) (mailsync.bin + 0x43af48)
#2 SyncWorker::idleCycleIteration() (mailsync.bin + 0x261168)
#3 runForegroundSyncWorker() (mailsync.bin + 0x9e538)
#4 runBackgroundSyncWorker()::{lambda()#1}::operator()() const (mailsync.bin + 0x9e834)
#5..#10 std::thread plumbing

3

Confirming the same crash on a different setup: identical frames and offsets (+0x444100, +0x4442f0, +0x269883).

Setup

  • Kubuntu 26.04 (Plasma 6.6.4, Wayland), kernel 7.0.0, x86_64
  • Installed via .deb from GitHub releases (not Snap), so not packaging-specific
  • Crashes on 1.25.0 (1.25.0-add26bb9); downgrading to 1.24.1 (1.24.1-05fe31c9) stopped it

Additional trigger: network change
Besides the periodic IDLE refresh, I can trigger it by pausing or reconnecting my VPN (NordVPN/WireGuard). About 2–3 minutes later, several accounts crash at the same moment. Same path as yours: Idle exited with code 1 → takeVanishedMessages() → collectVanishedFromLastResponse() → SIGSEGV.

Gmail doesn’t crash, custom-domain IMAP does
My Gmail account (OAuth) hits the same connection drop, logs ErrorConnection, and reconnects normally. Only my custom-domain IMAP accounts [host/server software, if known] segfault. Since Gmail doesn’t support QRESYNC, this points at the VANISHED handling when the IDLE connection ends abnormally.

At crash time, the background worker for the same account was blocked in mailimap_status/mailimap_list → mailstream_low_compress_read (COMPRESS enabled).

Core dumps available if useful.