### Author:  [@mzhaase](https://support.stalw.art/u/mzhaase)
#### Post date: [October 27, 2026, 11:30am UTC](https://support.stalw.art/t/stalwart-migrate-1-0-1-segfault-on-aarch64/2060/1 "2026-10-27T11:30:28Z")
### Issue Description
Running stalwart-migrate run on Ubuntu 24.04, arm64 results in segfault.
### Expected Behavior
No segfault!
### Actual Behavior
Segfault!
### Reproduction Steps
Just follow the regular migration - prepare, then run.
### Relevant Log Output
Offsets
Frame Address in core vaddr (for symbols) File offset (for bytes on disk)
#0 (PC) 0xc527b0b9b074 0x3b9b074 0x3b8b074
#1 0xc527b0a9f414 0x3a9f414 0x3a8f414
#2 0xc527b0a9e8a0 0x3a9e8a0 0x3a8e8a0
#3 0xc527b0a9cfd0 0x3a9cfd0 0x3a8cfd0
#4 0xc527b0a9cea4 0x3a9cea4 0x3a8cea4
#5 0xc527b09799d4 0x39799d4 0x39699d4
From coredump:
(gdb) bt
#0 0x0000c527b0b9b074 in ?? ()
#1 0x0000c527b0a9f414 in ?? ()
#2 0x0000c527b0a9e8a0 in ?? ()
#3 0x0000c527b0a9cfd0 in ?? ()
#4 0x0000c527b0a9cea4 in ?? ()
#5 0x0000c527b09799d4 in ?? ()
#6 0x0000c527aee30b38 in ?? ()
#7 0x0000c527af709180 in ?? ()
#8 0x0000c527af708524 in ?? ()
#9 0x0000c527af70c9a0 in ?? ()
#10 0x0000c527b02a9940 in ?? ()
#11 0x0000e87c5e1a582c in start\_thread (arg=0xe87c5e3b6b80) at ./nptl/pthread\_create.c:447
#12 0x0000e87c5e20bb4c in thread\_start () at ../sysdeps/unix/sysv/linux/aarch64/clone3.S:76
(gdb) info threads
Id Target Id Frame
- 1 Thread 0xe87c30f9e840 (LWP 112312) 0x0000c527b0b9b074 in ?? ()
2 Thread 0xe87c3fdee840 (LWP 112417) 0x0000e87c5e1a1d6c in \_\_futex\_abstimed\_wait\_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0,
futex\_word=0xe87c3fde7658) at ./nptl/futex-internal.c:57
3 Thread 0xe87c3d38e840 (LWP 112470) syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38
4 Thread 0xe87c4c3cd840 (LWP 112415) 0x0000e87c5e1a1d6c in \_\_futex\_abstimed\_wait\_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0,
futex\_word=0xe87c4c3c6658) at ./nptl/futex-internal.c:57
5 Thread 0xe87c3cf9e840 (LWP 110677) syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38
6 Thread 0xe87c3f7ee840 (LWP 111905) 0x0000e87c5e20be74 in \_\_GI\_epoll\_pwait (epfd=3, events=0xc527bd263db0, maxevents=1024, timeout=10624, set=0x0)
at ../sysdeps/unix/sysv/linux/epoll\_pwait.c:40
7 Thread 0xe87c4fffe840 (LWP 110267) 0x0000e87c5e1a1d70 in \_\_futex\_abstimed\_wait\_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0,
futex\_word=0xc527bd254668) at ./nptl/futex-internal.c:57
8 Thread 0xe87c3d7ae840 (LWP 112468) syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38
9 Thread 0xe87c3d59e840 (LWP 112469) syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38
10 Thread 0xe87c5deae840 (LWP 110263) syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38
11 Thread 0xe87c31fbe840 (LWP 112314) 0x0000e87c5e1a1d6c in \_\_futex\_abstimed\_wait\_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0,
futex\_word=0xe87c31fbd6a8) at ./nptl/futex-internal.c:57
12 Thread 0xe87c3fffe840 (LWP 112416) 0x0000e87c5e1a1d6c in \_\_futex\_abstimed\_wait\_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0,
futex\_word=0xe87c3fff7658) at ./nptl/futex-internal.c:57
13 Thread 0xe87c317ae840 (LWP 112313) 0x0000e87c5e1a1d6c in \_\_futex\_abstimed\_wait\_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0,
futex\_word=0xe87c317ad6a8) at ./nptl/futex-internal.c:57
14 Thread 0xe87c32fde840 (LWP 111083) syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38
15 Thread 0xe87c3fbde840 (LWP 112418) syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38
16 Thread 0xe87c5e0be840 (LWP 110262) syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38
17 Thread 0xe87c3dfbe840 (LWP 111084) syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38
18 Thread 0xe87c4c5dd840 (LWP 112324) syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38
19 Thread 0xe87c17ffe840 (LWP 112311) 0x0000e87c5e1a1d6c in \_\_futex\_abstimed\_wait\_common64 (private=0, cancel=true, abstime=0xe87c17ffddd8, op=393,
expected=0, futex\_word=0xc527bd24e408) at ./nptl/futex-internal.c:57
20 Thread 0xe87c3e7ce840 (LWP 111085) syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38
21 Thread 0xe87c3efde840 (LWP 111086) syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38
22 Thread 0xe87c5d90d840 (LWP 110264) 0x0000e87c5e1a1d6c in \_\_futex\_abstimed\_wait\_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0,
futex\_word=0xc527bd263a68) at ./nptl/futex-internal.c:57
23 Thread 0xe87c5d0fd840 (LWP 110265) 0x0000e87c5e1a1d6c in \_\_futex\_abstimed\_wait\_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0,
futex\_word=0xc527bd263a6c) at ./nptl/futex-internal.c:57
24 Thread 0xe87c5c8ed840 (LWP 110266) 0x0000e87c5e1a1d6c in \_\_futex\_abstimed\_wait\_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0,
futex\_word=0xc527bd263a6c) at ./nptl/futex-internal.c:57
25 Thread 0xe87c3c78e840 (LWP 112471) 0x0000e87c5e1a1d6c in \_\_futex\_abstimed\_wait\_common64 (private=0, cancel=true, abstime=0x0, op=393, expected=0,
futex\_word=0xe87c3c7812e8) at ./nptl/futex-internal.c:57
26 Thread 0xe87c5e3b6440 (LWP 110261) syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38
27 Thread 0xe87c4c7ed840 (LWP 112315) 0x0000e87c5e207d4c in \_\_GI\_munmap () at ../sysdeps/unix/syscall-template.S:120
(gdb) p $\_siginfo
$1 = {si\_signo = 11, si\_errno = 0, si\_code = 1, \_sifields = {\_pad = {240, 0 \}, \_kill = {si\_pid = 240, si\_uid = 0}, \_timer = {si\_tid = 240,
si\_overrun = 0, si\_sigval = {sival\_int = 0, sival\_ptr = 0x0}}, \_rt = {si\_pid = 240, si\_uid = 0, si\_sigval = {sival\_int = 0, sival\_ptr = 0x0}},
\_sigchld = {si\_pid = 240, si\_uid = 0, si\_status = 0, si\_utime = 0, si\_stime = 0}, \_sigfault = {si\_addr = 0xf0}, \_sigpoll = {si\_band = 240, si\_fd = 0},
\_sigsys = {\_call\_addr = 0xf0, \_syscall = 0, \_arch = 0}}}
(gdb) p/x $\_siginfo.\_sifields.\_sigfault.si\_addr
$2 = 0xf0
(gdb) x/6i $pc-8
0xc527b0b9b06c: clrex
0xc527b0b9b070: mov x9, x8
=\> 0xc527b0b9b074: ldr x8, [x8, #240]
0xc527b0b9b078: cmp x8, x19
0xc527b0b9b07c: b.ne 0xc527b0b9b070 // b.any
0xc527b0b9b080: str x22, [x9, #240]
(gdb) info registers
x0 0x85e4 34276
x1 0xe87c30f9d5c0 255620095268288
x2 0xe87c30f9d2e8 255620095267560
x3 0x1 1
x4 0x0 0
x5 0xc527bdb9ad90 216774477458832
x6 0xfffffffffffffff0 -16
x7 0x3 3
x8 0x0 0
x9 0x0 0
x10 0x30 48
x11 0x5 5
x12 0x0 0
x13 0x0 0
x14 0xfffffffffffff000 -4096
x15 0x0 0
x16 0x1 1
x17 0xe87c5e1aa5c4 255620852393412
x18 0x5 5
x19 0xe87c4c3c6570 255620552615280
x20 0xc527bdb9b0c0 216774477459648
x21 0x21080 135296
x22 0xe87c3c781200 255620288090624
x23 0xe87c3c781200 255620288090624
x24 0xe87c4c3c6570 255620552615280
x25 0xe87c4c3c6570 255620552615280
x26 0xe87c30f9d619 255620095268377
x27 0x0 0
x28 0xc527bdb9b280 216774477460096
x29 0xe87c30f9cf30 255620095266608
x30 0xc527b0a9f414 216774258324500
sp 0xe87c30f9cf30 0xe87c30f9cf30
pc 0xc527b0b9b074 0xc527b0b9b074
cpsr 0x80001000 [EL=0 BTYPE=0 SSBS N]
fpsr 0x10 [IXC]
fpcr 0x0 [Len=0 Stride=0 RMode=0]
tpidr 0xe87c30f9ef80 0xe87c30f9ef80
tpidr2 0x0 0x0
(gdb) info proc mappings
Mapped address spaces:
### Stalwart Version
v0.16.x
### Installation Method
Docker
### Database Backend
RocksDB
### Blob Storage
RocksDB
### Search Engine
Internal
### Directory Backend
Internal
### Additional Context
stalwart-migrate status --state ./migrate-state
State database: ./migrate-state/state.sqlite
tool\_version 1.0.1
edition enterprise
source\_def\_hash eac838c9ccd547f73f088f438c223eb6
target\_def\_hash 7fbcc15151bc4da024cd6b880c74bbd0
target\_schema\_version 7
categories settings,principals,mail,calendars,contacts,files,sieve,identities,push\_subscriptions,spam\_samples,reports,archive,spam\_model,queue,tasks,telemetry
created\_at 2026-10-27T10:19:24Z
source\_store directory /opt/container-data/stalwart/data
target\_claim 693c6a5a52f1b3766bbfdca4b163a2da
claim\_generation ffe6637f34a8633499680d1bee91a23a
claim\_generation\_pending ffe6637f34a8633499680d1bee91a23a
final\_done not done
Accounts: 8
done 4
full 4
Recent runs:
#12 incremental running started 2026-10-27T11:02:19Z
#11 incremental interrupted started 2026-10-27T10:59:05Z
#10 incremental interrupted started 2026-10-27T10:58:42Z
#9 incremental interrupted started 2026-10-27T10:40:31Z
#8 incremental interrupted started 2026-10-27T10:38:27Z
Reports in the latest run:
none
Reports in all runs:
info changed 23
warning dropped 61
### I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
### I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
### I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
on
---
### Author:  [@helpbot](https://support.stalw.art/u/helpbot)
#### Post date: [October 27, 2026, 11:30am UTC](https://support.stalw.art/t/stalwart-migrate-1-0-1-segfault-on-aarch64/2060/2 "2026-10-27T11:30:34Z")
This isn’t covered in the current docs. A community member or staff member will follow up.
_This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong._
---
### Author:  [@enaut](https://support.stalw.art/u/enaut)
#### Post date: [October 27, 2026, 12:10pm UTC](https://support.stalw.art/t/stalwart-migrate-1-0-1-segfault-on-aarch64/2060/3 "2026-10-27T12:10:06Z")
Oh so we created the same issue at the same time…
---
### Author:  [@rcfa](https://support.stalw.art/u/rcfa)
#### Post date: [October 27, 2026, 1:36pm UTC](https://support.stalw.art/t/stalwart-migrate-1-0-1-segfault-on-aarch64/2060/4 "2026-10-27T13:36:04Z")
Same crash here: stalwart-migrate 1.0.1 (standard build), aarch64, Debian-based (glibc 2.43), Oracle Cloud Ampere A1 with 4 vCPUs and 23 GiB RAM. The source was Stalwart 0.16.27 on RocksDB, running during the run, with a file system blob store (`blob_mode=Shared`). The target was a new, empty RocksDB directory.
The crashing PC and the next two frames match yours exactly, reached through a different call path:
```auto
Signal: 11 (SEGV) si_code: SEGV_MAPERR (binary sha256 c1a2d6fa52dfbfbb965f0aa49bff8d2b0896043c1b7e518290ef65d17e1bf6c2)
#0 +0x3b9b074 #7 +0x198d664 #14 +0x360dfd8
#1 +0x3a9f414 #8 +0x19193cc #15 +0x3616b54
#2 +0x3a9e8a0 #9 +0x1c9d308 #16 +0x35fdd1c
#3 +0x3d5f834 #10 +0x1bfb0a4 #17 +0x3606f9c
#4 +0x397be8c #11 +0x1886268 #18 +0x32a9940
#5 +0x3319e64 #12 +0xfcebd8 #19 start_thread (libc)
#6 +0x18bac50 #13 +0x360f7a0
```
It happened on the first `run` after `prepare`, with default concurrency (`concurrency=16`, `--account-split` default). That was about 75 s in, with roughly 76,000 emails written while two large accounts copied in parallel at about 2,000 emails/s. Nothing was printed before the crash, and there was no memory pressure (about 3 GiB in use).
**Workaround:** re-running the same command with `--concurrency 4 --account-split 2` resumed and finished: 887,590 emails in 18.7 min, 0 errors. Two more incremental runs, `run --final` and its verification also went through at that concurrency, and we’re now on 1.0.0. So it looks concurrency-dependent, which may help anyone else who hits it.
I can’t share the core dump (it holds mailbox contents), but I’m happy to run gdb commands against it while it’s still around.
---
### Author:  [@mzhaase](https://support.stalw.art/u/mzhaase)
#### Post date: [October 27, 2026, 3:48pm UTC](https://support.stalw.art/t/stalwart-migrate-1-0-1-segfault-on-aarch64/2060/5 "2026-10-27T15:48:04Z")
Tried with that workaround but still crashes for me.
---
### Author:  [@enaut](https://support.stalw.art/u/enaut)
#### Post date: [October 27, 2026, 6:23pm UTC](https://support.stalw.art/t/stalwart-migrate-1-0-1-segfault-on-aarch64/2060/6 "2026-10-27T18:23:33Z")
for me changing those parameters does not help either.
---
### Author:  [@stalwart](https://support.stalw.art/u/stalwart)
#### Post date: [October 27, 2026, 6:27pm UTC](https://support.stalw.art/t/stalwart-migrate-1-0-1-segfault-on-aarch64/2060/7 "2026-10-27T18:27:30Z")
Thanks for the core dumps, @rcfa and @mzhaase. With the crash addresses we could match the faulting instruction in the 1.0.1 binary, and from there it wasn’t hard to find.
It’s a bug in RocksDB’s write queue that only our aarch64 builds expose. In early October we upgraded the toolchain the arm64 binaries are built with, and the new one compiles RocksDB’s atomic compare-and-swap differently. Under concurrent writes that operation can fail spuriously on arm64, and RocksDB then follows a NULL pointer. That’s the `si_addr = 0xf0` in your dumps. x86\_64 builds can’t hit it, and it also explains why lowering `--concurrency` only helps sometimes: it makes the crash less likely without ruling it out.
The fix goes out in the next weekly Stalwart release and in the next stalwart-migrate release, for both the gnu and musl aarch64 builds. Your existing state database is fine; once you have the new binary, just run the same `stalwart-migrate run` again and it picks up where it stopped.
If you’d like to finish before then, building stalwart-migrate from source on the arm64 machine with the system compiler avoids the problem. The steps are in the [README](https://github.com/stalwartlabs/stalwart-migrate#building-from-source).
---
### Author:  [@mzhaase](https://support.stalw.art/u/mzhaase)
#### Post date: [October 29, 2026, 10:10am UTC](https://support.stalw.art/t/stalwart-migrate-1-0-1-segfault-on-aarch64/2060/8 "2026-10-29T10:10:36Z")
Ok, finished it with migrate 1.0.3 and that worked fine. Thanks! I especially liked that although it crashed a couple times, the migrate tool was very robust in just picking it back up.