First of all, thank you very much for working on this allocator (it seems that it's still the only one feature-rich enough for wasm in Rust)!

After a recent upgrade to Rust 1.78 our application started getting a panic message:

panicked at /rust/deps/dlmalloc-0.2.6/src/dlmalloc.rs:1198:13:
assertion failed: psize <= size + max_overhead

I've tried re-compiling the wasm module on 1.76 and 1.77 and did not get the panic message.
I believe this could be related to recent changes in the Rust compiler which are causing this misbehavior:

https://blog.rust-lang.org/2024/05/02/Rust-1.78.0.html#asserting-unsafe-preconditions
https://blog.rust-lang.org/2024/05/02/Rust-1.78.0.html#deterministic-realignment

Honestly, I don't feel competent enough to dig into the dlmalloc code and debug our wasm module but I'll be happy to get some guidance or help with debugging this issue.

PS: Our application is open-source and the wasm build can be found here: https://github.com/Stremio/stremio-core-web

I'm the author of another allocator for WASM, talc. I'm assuming this is still the default allocator in WASM?

In issues SFBdragon/talc#17 and SFBdragon/talc#24 I've had devs assume my allocator had a bug. Both times it turned out that the issue was with incorrectly sized layouts being passed to dealloc. Talc relies on the invariant stipulated by the safety contract of dealloc, but dlmalloc ignored this value entirely. The lol_alloc crate also relies on this, but will usually just "leak" memory instead.

I think this is a problem: it allows devs to write concealed bugs that only manifest if they override the global allocator (or a crate that depends on the buggy crate does so). This is completely avoidable, by having a debug assertion that the layout.size() equals the size stored internally by dlmalloc. Same goes for resize, I believe.

Side effects may include breaking some crates that violate the safety contract of dealloc/resize but have only been used with dlmalloc. I think this is necessary though. This implementation is setting an expectation as the default global allocator on WASM, and this expectation is a safety violation.

Happy to submit a PR, although I can't do it right now.

I've been using dlmalloc for the Xous port for the past few months, and I'd like to start upstreaming things into libstd. Would it be possible to bump the version of dlmalloc and make a new release on crates.io so that I can pull it into Rust?

Found by @evverx in systemd/systemd#19598 (comment):

test dlmalloc::tests::treemap_alloc_max ... error: Undefined Behavior: null pointer is not a valid pointer for this operation
    --> /home/vagrant/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mut_ptr.rs:242:18
     |
242  |         unsafe { intrinsics::offset(self, count) as *mut T }
     |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ null pointer is not a valid pointer for this operation
     |
     = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
     = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information

     = note: inside `core::ptr::mut_ptr::<impl *mut u8>::offset` at /home/vagrant/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mut_ptr.rs:242:18

Hi, thanks for the awesome crate.

So, allocating lots of things causes 5 second spike in the browser:

However preallocating memory before the main function reduces the spike to 66 ms.

pub fn prealloc_fast(len: usize) {
    let mut v: Vec<u8> = Vec::with_capacity(len);
    let mut sum: u32 = 0;
    unsafe {
        v.set_len(len);
        let begin = v.as_mut_ptr();
        let end = begin.add(len);

        let mut iptr = begin;
        while iptr < end {
            iptr = iptr.add(64 * 1024);
            *iptr = 42;
            sum += *(iptr.add(1)) as u32;
        }
    }
    black_box(sum);
    drop(v);
}

pub fn black_box<T>(dummy: T) -> T {
    unsafe {
        let ret = std::ptr::read_volatile(&dummy);
        std::mem::forget(dummy);
        ret
    }
}

The sum doesn't let LLVM optimize the function out.

Of course, i'm using:
RUSTFLAGS = "-Clink-args=--max-memory=4294967296"
To bypass the 512 MB memory limit.

Is there any better way to speed up malloc or calloc, but without trashing memory?

Also preserving zeroed-mem allocations would be nice.
https://github.com/alexcrichton/dlmalloc-rs/blob/master/src/lib.rs#L125

why

error[E0425]: cannot find value `GlobalDlmalloc` in crate `dlmalloc`
  --> engine/src/lib.rs:36:52
   |
36 | static ALLOC: dlmalloc::GlobalDlmalloc = dlmalloc::GlobalDlmalloc;

'cargo test' fails - just a fyi...

Now, dlmalloc build fails with:

error[E0432]: unresolved import core::alloc::Alloc
--> /home/xyz/.cargo/registry/src/github.com-1ecc6299db9ec823/dlmalloc-0.1.3/src/lib.rs:21:19
|
21 | use core::alloc::{Alloc, Layout, AllocErr};
| ^^^^^ no Alloc in alloc

Great project!

What do you think about adding a feature flag that causes this crate to implement the libc malloc API (i.e. extern "C" malloc, realloc, calloc, free, and maybe posix_memalign) for linked C/C++ code to consume?

I have a mixed Rust/C project that I'm compiling to Wasm. I need a malloc implementation, because I'd like to use wasm32-unknown-unknown and not Emscripten, so that I can use wasm-bindgen. Also, to reduce the binary size, I'd like for my Rust and C code to share the same allocator.

I've hacked this in locally, so if you're in favor of it, I'd be up for submitting a PR.

This would allow using it in #![no_std] contexts.