Stream: beginners

Topic: Weird List.sum behaviour


view this post on Zulip Jamie Neubert Pedersen (Mar 31 2024 at 18:55):

Hi there. I have this bug in my program, that only shows up if I run it in it's entirety. It doesn't show up if I write out the individual function calls with static data. It's a bit of a mess and quite a few lines scattered across different files. I don't know the best way to go from here.

The crash happens when I try to sum an array

dbg "Crashes on the next call"
newSum = List.sum (List.map my2dArray List.sum)
dbg "Does never happen"

With an integer subtraction overflowed:

[MyProgram.roc:164] "Crashes on the next call" = "Crashes on the next call"
Roc crashed with:

        Integer subtraction overflowed!

Here is the call stack that led to the crash:


Optimizations can make this list inaccurate! If it looks wrong, try running without `--optimize` and with `--linker=legacy`

I've tried to print out the 2d array and hardcode it and call the function with the hardcoded array instead of pointing to the variable and that doesn't crash.

view this post on Zulip Brendan Hansknecht (Mar 31 2024 at 18:57):

So I think we have a bug (no idea the cause) that screws up some of our builtin panic messages. That is probably actually an integer addition overflowed

view this post on Zulip Brendan Hansknecht (Mar 31 2024 at 18:57):

Due to all of the summing.

view this post on Zulip Brendan Hansknecht (Mar 31 2024 at 18:58):

What are the types? What size are the values?

view this post on Zulip Jamie Neubert Pedersen (Mar 31 2024 at 19:00):

The weird thing is it works when I do the dbg to get the actual array and throw it in, but maybe the type get's changed there. Can I check the type of the array of something? (I haven't explicitly typed anything)

view this post on Zulip Hristo (Mar 31 2024 at 19:01):

So I think we have a bug (no idea the cause) that screws up some of our builtin panic messages.

My response is only tangentially related to the topic (i.e., my example didn't have to do with List.sum per se) - my apologies. Wanted to mention that I've run into a case which confirms this statement. An U64 overflow was happening via subtraction, but I was getting a message saying Integer addition overflowed!.

view this post on Zulip Brendan Hansknecht (Mar 31 2024 at 19:02):

Is it related to --optimize or not?

view this post on Zulip Brendan Hansknecht (Mar 31 2024 at 19:04):

Also, is this code run once or in some form of loop?

view this post on Zulip Jamie Neubert Pedersen (Mar 31 2024 at 19:06):

I just run it with roc dev. I don't know about the --optimize is that something I can turn off?
It's run recursively, so yeah in some loop.

But is it possible to check the type of the list at runtime so I can answer your question regarding the type?

view this post on Zulip Brendan Hansknecht (Mar 31 2024 at 19:09):

dev will have --optimize off.

view this post on Zulip Brendan Hansknecht (Mar 31 2024 at 19:09):

The type should be I64 if you didn't type anything and it is a number

view this post on Zulip Brendan Hansknecht (Mar 31 2024 at 19:11):

Though may not be depending on exactly where the numbers come from and how they are used. There is no runtime reflection or type information in roc. So you can't easily check at runtime.

view this post on Zulip Brendan Hansknecht (Mar 31 2024 at 19:14):

There is definitely a solid chance that this is related to a large bug we have with current tail call optimization and llvm. #6434 tracks a mix of related issues.

view this post on Zulip Brendan Hansknecht (Mar 31 2024 at 19:14):

Any chance you can share the source code? Preferably something minimized that still hits the bug, but the full thing is fine too.

view this post on Zulip Jamie Neubert Pedersen (Mar 31 2024 at 19:20):

I would probably be able to zip it and send it to you, but for now I've at least found out that if I make a list of I8 then if I try to sum them, the result tries to stay as the same data type (which might be by design or not). I don't know if that is what my program ends up with.

my2DArray : List (List I8) # Works fine if commenting out this line
my2DArray = [[0, 1, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 1, 1, 0, 0, 0, 0, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 1, 0, 0, 0, 1, 0, 0, 0, 1, 1, 0, 1, 1, 1, 0, 1], [0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1], [0, 1, 1, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 0, 0, 1], [0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 0, 0, 1, 0, 1, 0, 1], [0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 0, 0, 1, 0, 1, 0, 1], [0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 0]]

first = List.map my2DArray List.sum
dbg first
dbg List.sum first

Crashes

[main.roc:26] first = [26, 26, 25, 24, 24, 24]
Roc crashed with:

        Integer addition overflowed!

Here is the call stack that led to the crash:

(Side note. Shouldn't there be a call stack in the blank space?)

view this post on Zulip Brendan Hansknecht (Mar 31 2024 at 19:39):

Yeah, roc won't automatically upcast when summimg

view this post on Zulip Brendan Hansknecht (Mar 31 2024 at 19:39):

Try with --linker=legacy, that might get you a call stack.


Last updated: Jul 06 2025 at 12:14 UTC