I'm intrigued with Roc, and started taking a look at https://github.com/roc-lang/roc/issues/6688. I traced the crash call through parsing, canonicalization, and specialization; I believe it comes down to calling the platform here. I've tested this locally with basic-cli 0.10.0, and I can confirm crash exits with code 0. However, it looks to me like the roc_panic
call should be landing in this codepath, which we should be exiting with code 1. Is anyone able to help correct my mental model so I can understand this behavior?
So.....this is actually a much bigger bug that I'm really not sure the cause of..... essentially, while crashing, the app probably crashed in a way that blocked the exit code. So crashed while crashing leading to a wrong exit code. I'm a bit surprised the exit code was zero and not random memory garbage.
So probably a form of this issue: https://github.com/roc-lang/roc/issues/6121
Probably a surgical linker bug
You can try testing with --linker=legacy
Thanks! When running with roc --linker=legacy main.roc
with the following main.roc
app [main] { pf: platform "https://github.com/roc-lang/basic-cli/releases/download/0.10.0/vNe6s9hWzoTZtFmNkvEICPErI9ptji_ySjicO6CkucY.tar.br" }
main = crash "CRASH"
I get the following output:
The program crashed with:
CRASH
Here is the call stack that led to the crash:
.libc
./csu/../sysdeps/nptl/libc_start_call_main.h
.libc
./csu/../csu/libc-start.c
Optimizations can make this list inaccurate! If it looks wrong, try running without `--optimize` and with `--linker=legacy`
I'm not entirely sure what to do with this; I may take a look at another issue where I can make forward progress on my own.
Did it give the correct exit code?
No, it exited with code 0; forgot to add that to the output note. :man_facepalming:
Last updated: Jul 05 2025 at 12:14 UTC