Stream: beginners

Topic: I got Error: SIGSEGV (Address boundary error)

Katsuki (Oct 26 2022 at 03:44):

Hi...
I am a beginner programmer on ROC language.
I got an error message terminated by signal SIGSEGV (Address boundary error)
In this code:

main = Program.noArgs mainTask

powDigit : U32 -> U32
powDigit = \nval ->
    cval = nval // 10
    rem = nval % 10
    when cval is
      0 -> rem * rem
      _ -> (rem * rem) + (powDigit cval)

pattern : U32 -> U32
pattern = \val ->
    pw = powDigit val
    when pw is
        1 -> 0
        89 -> 1
        _ -> pattern pw

loop : U32 -> U32
loop = \number ->
    when number is
        1 -> 0
        _ -> pattern number + (loop (number - 1))

mainTask =
    Stdout.line (1_000_000 |> loop |> Num.toStr)
     |> Program.exit 0

Is it segmentation fault error?

Brendan Hansknecht (Oct 26 2022 at 04:02):

I think it is a stack overflow

Brendan Hansknecht (Oct 26 2022 at 04:05):

yeah, definitely a stack overflow in my testing. It can get a bit farther with --optimize, but 1,000,000 leads to deep nesting of function calls. Since the function isn't tail recursive, it can't be turned into a loop.

Luke Boswell (Oct 26 2022 at 04:16):

Interesting... thinking out loud here... would it be possible for roc check to give you a warning when you have a recursion that is not tail-recursive? Maybe it could suggest another way to write it? I'm not sure how hard that would be to do in practice, but it seems important for a FP language where we don't have loops. Or would something like this also overflow in an iterative implementation?

Brendan Hansknecht (Oct 26 2022 at 04:34):

would it be possible for roc check to give you a warning when you have a recursion that is not tail-recursive?

Should be doable, the compiler at some point knows if a function is tail recursive. That said, it might be much later than the steps that roc check runs.

Maybe it could suggest another way to write it?

I would bet in most cases that would be really hard to do.

Or would something like this also overflow in an iterative implementation?

I think iterative would be fine. If this was rewritten in some sort of accumulator pattern, I would expect it to work.

Brian Carroll (Oct 26 2022 at 19:02):

It's worth noting that non-tail recursion is perfectly ok and deliberate in lots of cases! It's the only way to implement some algorithms. If you are implementing one of those cases, it would be weird to get a warning about your perfectly correct code, as if it's wrong. So although it's _possible_, I'm not sure it's a good idea.

Last updated: Jul 26 2025 at 12:14 UTC