Open markushauge opened 3 weeks ago
Very interesting, looks like a logic error in gc implementation, yet I can't reproduce it, even miri reports nothing. There should also be no platform-dependent code, (at least I see no cfgs only applicable to arm/macos/non-linux)
Could be some of assumptions made by gcmodule are wrong for ARM? Byte order should not matter, perhaps alignment?
Just to be sure, it is a native aarch64 build, and not rosetta-translated x86? (I don't see how it might fail either, but I want to reduce my search space)
Sorry, miri does report this error, I wasn't asking him nice enough. Thanks for the report, I'll investigate that!
Have found the problem, it is definitely just a logic error related to weak pointers
When we have no strong references (but have a weak references), gcmodule drops the Box contents (the tracked value), yet after no weak references left, gcmodule tries to drop Box itself, causing drop of the inner value again.
In this case, inner value happens to be another box (Cc<Box
jrsonnet segfaults when running in the default Rust dev profile (
cargo run
). I have created a minimal reproduction case here. The issue does not appear when running in release mode, or when running on Linux. Looking at LLDB and Miri, there seems to be some unsoundness injrsonnet-gcmodule
. Please let me know if you need more details.jrsonnet version: 0.5.0-pre95 OS: macOS Sonoma 14.6.1 Processor: Apple M1 Pro
Output
LLDB
Miri
With gcmodule debug feature