Ben Kimock

I'm looking at commit `749c3747356e233d84a33f376537695ffd2fa4e1`, and just doing `cargo +nightly run --release` or `cargo +stable run --release` does not segfault. I also tried adding `panic = "abort"` and still no...

I don't see any extra flags in there. I tried this on the M1 I have access to and I can't provoke a crash there either. I believe you that...

The crate doesn't have a repo link and I can't find it on @jam1garner's GitHub page. I downloaded the sources from crates.io, for example using https://github.com/saethlin/miri-tools/blob/50412bc80fd5966e53e103bde987bad7107bebc9/cargo-download/src/main.rs

Ah, perfect. I wasn't expecting any help from you, I think this is almost certainly just a Miri issue.

The problem you're having here is not related to this issue. In the invalid code you are creating an intermediate reference which only refers to the `GroupCount` member, which is...

What would fragment? The actual memory in the allocations is stored wherever the allocator linked into Miri decides to put it, right? And in any case, I suspect a minority...

Yeah, I think randomization is the way to go to. We don't need to pack allocations densely like a real allocator. In addition to that, we can keep a fixed-size...

I think there's a much easier way to do this: Carve up the whole address space ahead of time into N different bump allocators, and serve allocations by choosing randomly...

`force_eval!(0.0 / 0.0)` appears to not do anything at all: https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=2621c439604f11b4ef53462f228f8c33 ```rust fn main() { unsafe { println!("{:032b}", _mm_getcsr()); force_eval!(0.0 / 0.0); println!("{:032b}", _mm_getcsr()); } } ``` prints the same...

Oh neat, this bug was directly ported from musl.