I'm running out of ideas for why this fails
#[test]
fn compare_list_dec() {
let a = RocList::from_slice(&[RocDec::from(1), RocDec::from(2)]);
drop(a);
}
this code gives me free(): invalid pointer
. but from what I can observe nothing weird is going on
[crates/roc_std/src/roc_list.rs:781] unsafe { libc::malloc(size) } = 0x00007fe20c000b60
[crates/roc_std/src/roc_list.rs:539] self.ptr_to_allocation() = 0x00007fe20c000b60
[crates/roc_std/src/roc_list.rs:542] self.ptr_to_allocation() = 0x00007fe20c000b60
[crates/roc_std/src/roc_list.rs:547] self.ptr_to_allocation() = 0x00007fe20c000b60
[crates/roc_std/src/roc_list.rs:553] self.ptr_to_allocation() = 0x00007fe20c000b60
[crates/roc_std/src/roc_list.rs:555] needs_dealloc = true
[crates/roc_std/src/roc_list.rs:557] self.ptr_to_allocation() = 0x00007fe20c000b60
[crates/roc_std/src/roc_list.rs:563] self.ptr_to_allocation() = 0x00007fe20c000b60
end of life 0x7fe20c000b60
[crates/roc_std/src/roc_list.rs:798] unsafe { libc::free(c_ptr) } = ()
free(): invalid pointer
so are there any other odd ways in which a pointer can be invalid?
more fun
#[derive(Clone)]
#[repr(C, align(16))]
struct F(u32);
#[derive(Clone)]
#[repr(C, align(8))]
struct G(u32);
let a = RocList::from_slice(&[G(0), G(1)]);
drop(a);
the 8-byte alignment works fine, 16-byte alignment gives segfaults
and it's a bug in roc_std that's just been there since forever
Yeah, I have wanted to rewrite the roc std impl for a while. I think it is overly clever and that makes it confusing to follow. Also with seamless slices and the representation of list and str diverging some, I think it is wrong in some places.
As for this bug...really strange that it depends on alignment even though it is just freeing through malloc/free.
Anyway, can you run with valgrind?
Maybe also double check we aren't generating code trying to free the decs in the list for some reason. That definitely could lead to a double free and invalid pointer.
Last updated: Jul 06 2025 at 12:14 UTC