# Segmentation fault in stalwart-migrate

**URL:** https://support.stalw.art/t/segmentation-fault-in-stalwart-migrate/2059
**Category:** Issues
**Created:** [October 27, 2026, 11:29am UTC](https://support.stalw.art/t/segmentation-fault-in-stalwart-migrate/2059 "2026-10-27T11:29:51Z")
**Posts on this page:** 1
**Showing post:** 6

<div class="post-metadata">

### Author: ![stalwart](https://support.stalw.art/user_avatar/support.stalw.art/stalwart/32/12_2.png) [@stalwart](https://support.stalw.art/u/stalwart)
#### Post date: [October 27, 2026, 6:27pm UTC](https://support.stalw.art/t/segmentation-fault-in-stalwart-migrate/2059/6 "2026-10-27T18:27:38Z")

</div>

Hi @enaut, this one is on our side. It’s the same arm64 crash as in [the other topic](https://support.stalw.art/t/stalwart-migrate-1-0-1-segfault-on-aarch64/2060), and it has nothing to do with your config or the 0.16 version you migrate from, so the upgrade to 0.16.27 couldn’t have helped.

The cause is how our aarch64 release binaries were compiled: RocksDB’s write queue uses an atomic operation that, in this build, can fail spuriously under concurrent writes, and RocksDB then dereferences a NULL pointer. That’s why it dies a few seconds into the account pass with nothing in the log.

It’s fixed for the next weekly Stalwart release and the next stalwart-migrate release. Your state in `/var/lib/stalwart-migrate-v1` stays valid, so rerunning the same command with the new binary continues from there. If you don’t want to wait, a stalwart-migrate built from source on the server itself doesn’t have the problem; see [Building from source](https://github.com/stalwartlabs/stalwart-migrate#building-from-source) (keep the default `enterprise` feature, since your status shows the enterprise edition).

---

_[View the full topic](https://support.stalw.art/t/segmentation-fault-in-stalwart-migrate/2059)._