Stream: compiler development

Topic: Windows bug


view this post on Zulip Luke Boswell (Oct 14 2024 at 09:04):

Does this error message give us any clues?? what is the deserialize_solved_implementations about?

Running `target\debug\roc.exe --linker=surgical .\examples\platform-switching\rocLovesRust.roc`
thread 'main' panicked at library\core\src\panicking.rs:221:5:
unsafe precondition(s) violated: slice::from_raw_parts requires the pointer to be aligned and non-null, and the total size of the slice not to exceed `isize::MAX`
stack backtrace:
   0: std::panicking::begin_panic_handler
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\std\src\panicking.rs:665
   1: core::panicking::panic_nounwind_fmt::runtime
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\core\src\panicking.rs:112
   2: core::panicking::panic_nounwind_fmt
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\core\src\panicking.rs:122
   3: core::panicking::panic_nounwind
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library\core\src\panicking.rs:221
   4: core::slice::raw::from_raw_parts::precondition_check
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c\library\core\src\ub_checks.rs:68
   5: core::slice::raw::from_raw_parts<u64>
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c\library\core\src\ub_checks.rs:75
   6: roc_serialize::bytes::deserialize_slice<u64>
             at .\crates\compiler\serialize\src\bytes.rs:35
   7: roc_can::abilities::serialize::deserialize_solved_implementations
             at .\crates\compiler\can\src\abilities.rs:1199
   8: roc_can::module::TypeState::deserialize
             at .\crates\compiler\can\src\module.rs:1243
   9: roc_load::deserialize_help
             at .\crates\compiler\load\src\lib.rs:240
  10: roc_load::read_cached_types
             at .\crates\compiler\load\src\lib.rs:266
  11: roc_load::load
             at .\crates\compiler\load\src\lib.rs:37
  12: roc_load::load_and_monomorphize
             at .\crates\compiler\load\src\lib.rs:143
  13: roc_build::program::build_file
             at .\crates\compiler\build\src\program.rs:732
  14: roc_cli::build
             at .\crates\cli\src\lib.rs:920
  15: roc::main
             at .\crates\cli\src\main.rs:46
  16: core::ops::function::FnOnce::call_once<enum2$<core::result::Result<tuple$<>,std::io::error::Error> > (*)(),tuple$<> >
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c\library\core\src\ops\function.rs:250
  17: core::hint::black_box
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c\library\core\src\hint.rs:389
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread caused non-unwinding panic. aborting.
error: process didn't exit successfully: `target\debug\roc.exe --linker=surgical .\examples\platform-switching\rocLovesRust.roc` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)

view this post on Zulip Luke Boswell (Oct 14 2024 at 09:54):

Apparently the issue is in crates\compiler\serialize\src\bytes.rs

Specifically in deserialize_slice. I've added an assert that fails.

assertion `left == right` failed: Misaligned pointer for type T
  left: 4
 right: 0
pub fn deserialize_slice<T: Copy>(bytes: &[u8], length: usize, mut offset: usize) -> (&[T], usize) {
    let alignment = std::mem::align_of::<T>();
    let size = std::mem::size_of::<T>();

    offset = next_multiple_of(offset, alignment);

    let byte_length = length * size;
    let byte_slice = &bytes[offset..][..byte_length];

    // Check if the pointer is properly aligned
    assert_eq!(
        (byte_slice.as_ptr() as usize) % alignment,
        0,
        "Misaligned pointer for type T"
    );

    let slice = unsafe { std::slice::from_raw_parts(byte_slice.as_ptr() as *const T, length) };

    (slice, offset + byte_length)
}

But I'll need to stare at this for a while before I convince myself I can understand what is happening here. It obviously works fine on linux and macos, just failing on my windows machine.

view this post on Zulip Luke Boswell (Oct 14 2024 at 09:59):

@Folkert de Vries just wondering if this might be a red-herring... do you have any intuition for what might be the issue here?

view this post on Zulip Notification Bot (Oct 14 2024 at 10:04):

3 messages were moved here from #compiler development > Windows Surgical Linker Bug by Luke Boswell.

view this post on Zulip Folkert de Vries (Oct 15 2024 at 09:15):

no this is real. The input bytes slice must be aligned. It may be that on windows the system allocator has a lower alignment, or that the slice is to stack memory and on windows things are placed on the stack differently (different order, types have different sizes, whatever).

view this post on Zulip Folkert de Vries (Oct 15 2024 at 09:15):

in any case, you must get the caller to provide a properly-aligned slice somehow (and panic if it is not aligned, so keep that assert in there)

view this post on Zulip Folkert de Vries (Oct 15 2024 at 09:16):

(btw I'll be in China from here on out, so, good luck, and I'll check back in in next monday)


Last updated: Jul 06 2025 at 12:14 UTC