As flabbergasted as I've been to witness it, I've run into a Segmentation fault (core dumped)
message, when working with pure Roc code (i.e., no platforms, it's an interface file, with a bunch of expect
tests).
The error occurred in the context of my attempting to do conversion gymnastics (going through Dec
and Frac
), in order to be able to (string) format F64
values with a decimal point, when their values after the decimal point are 0
s.
I'll try to provide a minimal reproducible example.
Please, note that this might be due to my local environment, as I've been experiencing issues with parsing F64
from Str
in the REPL. However, the issue which I'm referring to above isn't limited to the REPL (as I mentioned, it occurs as a result of roc test ...
). Just to confirm, this is in the context of a 64-bit machine (my Roc experiments have been conducted running inside a Docker container). I'll try to reproduce the issue on a different machine as well.
On a related note, is there a way to format an F64
with a value of 5.0
as "5.0"
(rather than "5"
) via Num.toStr
?
The only way I could think of is via Num.toFrac
, but I'm getting this error:
» p : Num.F64
… p = 10.0
10 : F64
» Num.toFrac p
thread 'main' panicked at 'not yet implemented: NumToFrac: layout, arg Builtin(Float(F64)), ret InLayout(DEC)', crates/compiler/gen_dev/src/generic64/mod.rs:5089:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Thanks!
Any segfaults while running roc test
on an interface file is certainly a compiler bug. If you can log an issue with a reproduction that would be super helpful.
For formatting numbers to Str
, I think it has been discussed before but I can't recall the discussion. I feel like the best solution long term will be a userspace library that provides that functionality.
I've implemented similar formatting functions in isolation in small parts where I've needed them, but a larger package with better support and functionality would be really helpful.
Also the crash in the REPL thread 'main' panicked at 'not yet implemented: NumToFrac
is likely due to an unimplemented function in one of the dev backends.
Thanks for your response, @Luke Boswell!
Yes, that's indeed the case regarding the panic - it appears that toFrac
is only defined for integer types, which is understandable.
I also do appreciate the suggestion regarding a user-space library. That's what I eventually resorted to - adding the ".0" in what felt originally as a hacky way (something that could be expanded to some more elaborate and flexible formatting functionality), but I do appreciate it's in the category of functionalities which, by design or otherwise, haven't been intended to be offered by the standard library.
I think this can be closed as unable to reproduce, unless somebody else would like to try reproducing it via the old-Linux version.
The issue occurs only within the context of the 64-bit machine on which I'm running the old-Linux version of Roc:
> roc version
roc nightly pre-release, built from commit 7d51d2b on Fri Mar 8 09:08:29 UTC 2024
I haven't been able to reproduce the issue on an Apple M1.
Please, find a minimum reproducible example (and hence the one-letter names) as follows:
# SegFaultExample.roc
interface SegFaultExample
exposes []
imports []
# If `Dec` is changed to `F64`, there is no segfaultt.
T : Dec
Q : (Str, T)
f : List Str -> Dict Str T
f = \s ->
List.map s (\_ -> ("", 0.0)) |> g
g : List Q -> Dict Str T
g = \_ ->
Dict.empty {}
expect
_ = f [ "1", "2", "3", "4", "5", "6", "7" ]
# The segfault doesn't occur with the following though.
# _ = f [ "1", "2", "3", "4", "5", "6" ]
1 == 1
Please, have a look at the two comments as well, which showcase some of the observed odd behaviour.
> roc test SegFaultExample.roc
... [the warning regarding the unused list has been omitted for brevity]
0 errors and 1 warning found in 198 ms
.
Running tests…
──────────────────────────────────
Segmentation fault (core dumped)
Hristo has marked this topic as resolved.
Can you file an issue. That is a small enough report it is definitely worth digging into
I'll probably be able to reproduce it, I have machines for all Roc targets :)
Thanks @Brendan Hansknecht - shall do a bit later today!
Hi @Brendan Hansknecht :wave:
Apologies it took ages - I've finally found some time to create a GitHub ticket regarding this.
I confirm that I've got several workarounds, so this is in no way a blocker in my case.
Thanks!
Last updated: Jul 06 2025 at 12:14 UTC