Kevin Hovsäter (Oct 24 2021 at 13:24): Kevin Hovsäter (Oct 24 2021 at 13:24):I just tried to run the tests on macOS. All passed but one. Is this expected? This is using LLVM 12.0.1, Zig 0.8.1 and Rust 1.56.0.
Screenshot-2021-10-24-at-15.24.43.png
Richard Feldman (Oct 24 2021 at 13:26):definitely not expected! :thinking:
any ideas @Brendan Hansknecht?
Brendan Hansknecht (Oct 24 2021 at 15:37):Not off the top of my head. I guess it was never tested on Marcos, but I wouldnt expect it to be broken. Can some try to repro to see if it is broken on all Macs?
Richard Feldman (Oct 24 2021 at 15:43):works for me on Big Sur on an Intel Mac
Richard Feldman (Oct 24 2021 at 15:43):@Kevin Sjöberg are you on an Intel Mac or M1?
Richard Feldman (Oct 24 2021 at 15:44):also which macOS version?
Kevin Hovsäter (Oct 24 2021 at 15:50):Richard Feldman said:
Kevin Sjöberg are you on an Intel Mac or M1?
I'm on an Intel Mac. Running macOS Big Sur, 11.6.
Kevin Hovsäter (Oct 24 2021 at 15:55):@Richard Feldman this is what I see when I manually run that test case.
Screenshot-2021-10-24-at-17.54.45.png
Richard Feldman (Oct 24 2021 at 15:58):@Kevin Sjöberg never mind, I just realized I re-ran the tests on a branch that didn't have the false interpreter example merged in yet - when I ran on trunk I was able to reproduce what you're seeing :big_smile:
Kevin Hovsäter (Oct 24 2021 at 15:59):@Richard Feldman great. Glad it's not just me! :sweat_smile:
Richard Feldman (Oct 24 2021 at 16:01):yeah, although not sure what the issue might be :thinking:
Richard Feldman (Oct 24 2021 at 16:01):actually, I have one theory - there are currently two tests failing on macOS that I need to track down
Richard Feldman (Oct 24 2021 at 16:01):(we don't have macOS CI set up right now, only Linux, so OS-specific regressions happen from time to time)
Kevin Hovsäter (Oct 24 2021 at 16:02):I wish I could be more helpful, but I literally just touched Rust for the first time a moment ago. The error message seem to indicate we're trying to free memory not allocated through malloc. Seems weird it would be platform specific though.
Richard Feldman (Oct 24 2021 at 16:03):yeah we've seen something like that happen once in the past
Richard Feldman (Oct 24 2021 at 16:04):if I remember right, it turned out that we were always doing something wrong, but for some reason the way Linux implements malloc and free, it wasn't reporting the error (and maybe the memory happened to be untouched, so the use-after-free happened to not cause a problem in practice)
Kevin Hovsäter (Oct 24 2021 at 16:13):Is it fair to assume the error must be in the Roc implementation of the False interpreter given that the platform compiled correctly (I assume a use-after-free shouldn't really be possible in Rust-land either, right?)?
Richard Feldman (Oct 24 2021 at 16:19):in general a UAF is either a bug in the Roc compiler or a bug in the platform; it shouldn't be possible to get one from writing application code wrong (the false interpreter being the application in this case)
Richard Feldman (Oct 24 2021 at 16:20):almost certainly this is a compiler bug, although it is possible to get a UAF from Rust, depending on what you're doing :big_smile:
Kevin Hovsäter (Oct 24 2021 at 16:20):Got it. Thanks for explaining. This is all new to me. :smile:
Richard Feldman (Oct 24 2021 at 16:22):totally! That's why we have the #beginners channel! :grinning:
Brendan Hansknecht (Oct 24 2021 at 17:06):Oh this makes sense now.
Brendan Hansknecht (Oct 24 2021 at 17:07):If Mac os fails on a memory leak, that is different behavior than Linux. This test currently doesn't run with valgrind because it has a memory leak.
Brendan Hansknecht (Oct 24 2021 at 17:08):I guess i forgot to dig into/file a bug related to the false app having a memory leak.
Richard Feldman (Oct 24 2021 at 17:31):aha! Yeah would be great to have an issue for that :100:
Folkert de Vries (Oct 24 2021 at 17:43):Pretty sure the rust ffi is at least partially to blame
Folkert de Vries (Oct 24 2021 at 17:43):E.g. we learned recently that only extern "c" fn s are ffi safe
Brendan Hansknecht (Oct 24 2021 at 18:15):Yeah, it looks to be all rust related, working on a fix
Kevin Hovsäter (Oct 24 2021 at 19:31):Out of curiosity, how do you go about debugging something like this? Valgrind seems useful but I’ve had no luck getting it to work properly on macOS.
Brendan Hansknecht (Oct 24 2021 at 19:42):I almost always use linux, so no tips on getting valgrind working on macos, but in general, lldb/gdb and valgrind are quite useful for getting context around the location leaks are happening and investigating the instructions generated. That being said, a lot of the debugging is based on context of were the app could be allocating/deallocating memory. In this case, part of the bug is caused by rust dropping data that roc later tried to free.
Brendan Hansknecht (Oct 24 2021 at 19:42):I'm not sure that is the most useful answer, but I don't really have specific steps.
Tim Whiting (Oct 24 2021 at 20:37):Kevin Sjöberg said:
I just tried to run the tests on macOS. All passed but one. Is this expected? This is using LLVM 12.0.1, Zig 0.8.1 and Rust 1.56.0.
Back to this issue, I'm also seeing this on MacOS (not sure about other OSes). It seems like the arguments are not forwarded correctly to the application when using cargo test / cargo run. When I edit the platform to print the args it only has the first argument to the executable and not the executable name (which is the first arg of std::env::args when run standalone).
Brendan Hansknecht (Oct 25 2021 at 01:10):When using cargo run you need to separate the file name with a -- like cargo run examples/false-interpreter/False.roc -- examples/false-interpreter/examples/hello.false
Brendan Hansknecht (Oct 25 2021 at 01:11):That may be the cause of the specific issue you are seeing
Last updated: Jul 26 2025 at 12:14 UTC