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.
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
Due to all of the summing.
What are the types? What size are the values?
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)
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!
.
Is it related to --optimize
or not?
Also, is this code run once or in some form of loop?
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?
dev
will have --optimize
off.
The type should be I64
if you didn't type anything and it is a number
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.
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.
Any chance you can share the source code? Preferably something minimized that still hits the bug, but the full thing is fine too.
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?)
Yeah, roc won't automatically upcast when summimg
Try with --linker=legacy
, that might get you a call stack.
Last updated: Jul 06 2025 at 12:14 UTC