Stream: beginners

Topic: ✔ Segmentation fault (core dumped) during conversion


view this post on Zulip Hristo (Mar 11 2024 at 21:59):

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 0s.

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.

view this post on Zulip Hristo (Mar 11 2024 at 22:04):

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!

view this post on Zulip Luke Boswell (Mar 11 2024 at 23:27):

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.

view this post on Zulip Luke Boswell (Mar 11 2024 at 23:32):

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.

view this post on Zulip Luke Boswell (Mar 11 2024 at 23:33):

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.

view this post on Zulip Hristo (Mar 12 2024 at 06:39):

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.

view this post on Zulip Hristo (Mar 12 2024 at 20:32):

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)

view this post on Zulip Notification Bot (Mar 12 2024 at 20:34):

Hristo has marked this topic as resolved.

view this post on Zulip Brendan Hansknecht (Mar 13 2024 at 02:16):

Can you file an issue. That is a small enough report it is definitely worth digging into

view this post on Zulip Anton (Mar 13 2024 at 09:54):

I'll probably be able to reproduce it, I have machines for all Roc targets :)

view this post on Zulip Hristo (Mar 13 2024 at 10:40):

Thanks @Brendan Hansknecht - shall do a bit later today!

view this post on Zulip Hristo (Mar 15 2024 at 20:52):

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