Tokio | Actix compatability - Rust 1.7+ | default_features = true

[chriskyndrid]

Using mimalloc with a rust version >= 1.7 in combination with Tokio and/or Actix will cause a:

thread 'main' panicked at 'misaligned pointer dereference: address must be a multiple of 0x80 but is 0x333ae056ae0', /home/admin/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.29.0/src/runtime/task/core.rs:240:32

error to be thrown. This only happens in combination with rust version 1.7+ and Cargo.toml set as:

[dependencies.mimalloc]
version = "0.1"

Changing Cargo.toml to

[dependencies.mimalloc]
version = "0.1"
default-features = false

Is a functional workaround though obviously looses the beneficial security features. I have not setup a separate test project, so I cannot saw with 100% assurance some other component within my environment isn't impacting this, but a simple:

async fn main() -> SystemSyncResult<()> {
    use actix_web::App;
    use actix_web::HttpServer;

    let app = HttpServer::new(move || {
        App::new()
            .configure(api_config_all_v1)
    })
    .bind("127.0.01:8080")?;

    app.run().await?;

    log::info!("Shutdown complete");

    Ok(())
}

Should be sufficient to reproduce the issue. Disabling mimalloc or altering the default-features flag to false should resolve the problem.

I'm not sure what changed with the compiler in version 1.7, and/or in combination with libraries mentioned, that caused the problem to occur.

[thomcc]

This is from rust-lang/rust#98112. It indicates that this crate is returning a misaligned pointer, which is a soundness issue.

You should probably always disable this crates default features. I think the choice default features are very bad, and they probably aren't things that should be used in production (only development/debugging). That said, it's unfortunate that they're unsound.

This might be an upstream issue. It's also possible that the logic in https://github.com/purpleprotocol/mimalloc_rust/blob/master/src/lib.rs#L55-L56 is wrong now.

[chriskyndrid]

@thomcc, thanks for the feedback and information!

[Darksonn]

Tokio recently upped the alignment on the task allocation to combat false sharing performance issues, which should be the cause of the particular failure you ran into. Hence, for this particular instance of the problem, there's no impact other than performance when the alignment is ignored.

Of course, ignoring the alignment requirements of allocations will still be a problem in other situations.

[thomcc]

Yeah, it's definitely a soundness issue.

[chriskyndrid]

@Darksonn, thank you for the additional information. I ended up switching to this crate, which didn't exhibit the same behavior.

Plus it's labelled 'The Best and Highest-Leveled", so it gets bonus points.