@algernon do you have any idea why iocaine 3.1 would fail to build in the nix build sandbox with
thread 'main' (14154) panicked at /build/cargo-vendor-dir/cranelift-jit-0.120.2/src/compiled_blob.rs:56:80:
called `Result::unwrap()` on an `Err` value: TryFromIntError(())
right after a string of successful tests ending in "ok 3 - user agent (fennel)"?
i don't know how to set RUST_BACKTRACE=1 in the sandbox
nixocaine stable branch overlay
@zwol @algernon proximate cause of that error looks like an X86PCRel4 relocation trying to be filled in with an address that's more than 2GB away (https://github.com/bytecodealliance/wasmtime/blob/e06fe2c5132598259ae56cfc89f7574e46b36242/cranelift/jit/src/compiled_blob.rs#L56)
this raises questions for me like "what is iocaine using cranelift-jit for?" I spent enough time working on Cranelift to have a personal interest in that answer
@jamey iocaine doesn't directly use Cranelift, but it embeds Roto, and that uses Cranelift. iocaine itself is not much more than a runtime, a shell for Roto or Lua scripts, those do the heavy lifting, iocaine "merely" provides the tools.
I... I think I'm going to tag @terts in, because Cranelift is far beyond my capabilities. :(
@algernon @jamey @terts all I did was slot nixocaine into the flake inputs for my server configuration and then attempt to start a nix environment (not on the server, on my main workstation PC) with caddy and iocaine available.
I have had weird problems with nix environments on my workstation before. I can troubleshoot further but not till tomorrow and I'm going to need exact instructions.
@zwol @algernon @terts Based solely on the panic message, without any understanding of how Roto or iocaine is using this, I think there's probably a native function that's being passed into the script, and Roto and Cranelift are trying to hardcode the address as a 4-byte immediate operand on a call instruction, but the JIT-compiled code is being written to an address that happens, on this run, to be too far away from the function it's calling.
I'm going to guess that this has something to do with ASLR or other sources of non-determinism in how code and allocations got laid out across the virtual memory address space. If so, trying it again a few times might happen to succeed at random, or at least fail in different tests.
But I could be wrong about any or all of the above.
@zwol Uhh... no idea off the top of my head. I'll look into it (probably tomorrow morning).
