SharedVector ABI Mismatch on ARM Cortex-M7 Breaks All Layouts

[task-jp]

Bug Description

Summary

SharedVector is ABI-incompatible between Rust and C++ on ARM Cortex-M7 (32-bit).
Rust’s portable_atomic::AtomicIsize requires stricter alignment than C++’s std::atomic<std::intptr_t>, causing SharedVectorHeader to have different sizes on the two sides.

This results in a 4-byte mismatch in the computed data pointer (inner + 1), corrupting all vectors used by the layout engine.
UI layout becomes completely invalid on ARM32 devices.

---

Affected Platforms

• ARM Cortex-M7 (ARMv7-M 32-bit)
• Likely all ARM32 targets using portable-atomic fallback

Unaffected: x86-64, ARM64 (alignment happens to match)

---

Symptoms

On ARM32, UI layout behaves incorrectly:

• Item positions shifted / wrong ordering
• Incorrect sizes emitted by layout solver
• Overlapping / disappearing widgets
• All SharedVector-backed arrays contain corrupted data when read from C++

Rust-side logging shows correct values, but C++ reads wrong addresses.

---

Root Cause

1. Different atomic ABI between Rust and C++

Rust uses:

portable_atomic::AtomicIsize

On ARM32, this uses an 8-byte alignment fallback, even though the stored value is 32-bit.

C++ uses:

std::atomic<std::intptr_t>

which is 4-byte aligned on ARM32.

2. SharedVectorHeader size differs across languages

Field	Rust (AtomicIsize)	C++ (std::atomic<std::intptr_t>)
Alignment	8 bytes	4 bytes
Size	4 bytes + padding	4 bytes

Therefore:

• Rust: sizeof(SharedVectorHeader) == 16
• C++: sizeof(SharedVectorHeader) == 12

3. C++ computes data pointer as header + 1

auto data = reinterpret_cast<T*>(header + 1);

C++ believes data begins 12 bytes after the header,
while Rust places it 16 bytes after the header.

4. A consistent 4-byte underflow occurs

Rust memory:  [ header (16 bytes) ] [ data... ]
C++ reads:                  ^ starts here (−4 bytes)

Every vector read by C++ is shifted by 4 bytes, corrupting:

• child lists
• layout geometric properties
• repeated item vectors
• animation keyframes
• any SharedVector<T>

Reproducible Code (if applicable)

export component MainWindow inherits Window {
    width: 800px;
    height: 600px;

    HorizontalLayout {
        Rectangle {
            width: 300px;
            height: 200px;
            background: red;
        }
        Rectangle {
            width: 200px;
            height: 300px;
            background: blue;
        }
    }
}

Environment Details

• Slint Version: pre v1.15
• Platform/OS: NXP MIMXRT1170-EVK/Zephyr
• Programming Language:C++
• Backend/Renderer:

Product Impact

No response

[ogoffart]

I find it surprising that AtomicIsize has an alignment of 8 bytes.
But if it does, there might also be other problems than SharedVector such as VRc

[task-jp]

VRc uses AtomicU32 that has an alignment of 4 bytes.

https://doc.rust-lang.org/std/sync/atomic/struct.AtomicU32.html

[tronical]

Rust’s portable_atomic::AtomicIsize requires stricter alignment than C++’s std::atomic<std::intptr_t>

It would be really good to know what the source of that statement is. I wonder how to verify this - apart from a static assert?

[ogoffart]

I've tried to compile this program:

fn main() {
    static _X : [usize; 8] = [0; core::mem::align_of::<portable_atomic::AtomicIsize>()];
}

And with cargo check --target thumbv7em-none-eabi it complains:

cargo check --target thumbv7em-none-eabi
    Checking xxx v0.1.0 (/tmp/xxx)
error: `#[panic_handler]` function required, but not found

error[E0308]: mismatched types
 --> src/main.rs:4:30
  |
4 |     static _X : [usize; 8] = [0; core::mem::align_of::<portable_atomic::AtomicIsize>()];
  |                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected an array with a size of 8, found one with a size of 4

For more information about this error, try `rustc --explain E0308`.
error: could not compile `xxx` (bin "xxx") due to 2 previous errors

So it looks like portable_atomic::AtomicIsize alignment is 4 on that platform.
The binary incompatibility is probably somewhere else.

[ogoffart]

VRc uses AtomicU32 that has an alignment of 4 bytes.

But then I see no reason why AtomicUsize would also not have an alignment of 4 bytes.

How did you find out that the alignment is 8 bytes on that platform?