Yo yo everyone! I'm working on day 20 part 1 and I'm hitting a weird issue where Roc seems to stop execution with no error code. Part 1 of the puzzle is about finding a path through a maze, and then finding alternative faster paths if you can pass through a maze wall once. I have what I think is a working version (at least, it passes the sample input), but when I run on the full input, Roc stops execution and exits partway through.
My solution uses recursion to build paths, so I'm wondering if somehow Roc is running out of memory? This seems weird, because looking at memory usage while it's running before it stops, I don't see any large spike.
(Side note: Does Roc do tail call optimization? If so, my function isn't set up properly to take advantage of it right now, but maybe that could help.)
I added some dbg
logs to my solution in the recursive function to see at what point in solving the maze it stops and it seems to stop at a different point every time.
I also recorded a quick screen share going through the issue, any advice would be much appreciated!
Screen Recording 2024-12-20 at 11.32.45 AM.mov
If I build it with --optimized
then run, my shell produces:
× External command core dumped
╭─[entry #198:1:1]
1 │ src/day20
· ────┬────
· ╰── core dumped with SIGSEGV (11)
╰────
Welcome back @Jared Ramirez :)
If you are on linux, can you do roc build src/day20.roc --linker=legacy
followed by valgrind src/day20
and share the output here?
Here's the error output:
==512273== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==512273==
==512273== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==512273== Access not within mapped region at address 0x1FFE801D08
==512273== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
==512273== at 0x15F107: List_concat_55aa18fc3c82fe108fcf64fea07364ddba1e8c526b8d27b19692a7748519e1c (in /home/jared/dev/github/jaredramirez/advent-of-code-2024/src/day20)
==512273== If you believe this happened as a result of a stack
==512273== overflow in your program's main thread (unlikely but
==512273== possible), you can try to increase the size of the
==512273== main thread stack using the --main-stacksize= flag.
==512273== The main thread stack size used in this run was 8388608.
==512273==
==512273== HEAP SUMMARY:
==512273== in use at exit: 254,803,958 bytes in 14,127 blocks
==512273== total heap usage: 48,589 allocs, 34,462 frees, 264,887,292 bytes allocated
==512273==
==512273== LEAK SUMMARY:
==512273== definitely lost: 8 bytes in 1 blocks
==512273== indirectly lost: 0 bytes in 0 blocks
==512273== possibly lost: 254,802,926 bytes in 14,125 blocks
==512273== still reachable: 1,024 bytes in 1 blocks
==512273== suppressed: 0 bytes in 0 blocks
==512273== Rerun with --leak-check=full to see details of leaked memory
==512273==
==512273== For lists of detected and suppressed errors, rerun with: -s
==512273== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
hey Jared, great to see you! :smiley:
Does Roc do tail call optimization? If so, my function isn't set up properly to take advantage of it right now, but maybe that could help.
yes we do
My solution uses recursion to build paths, so I'm wondering if somehow Roc is running out of memory? This seems weird, because looking at memory usage while it's running before it stops, I don't see any large spike.
Stack space is limited to I think 8MB by default on linux, so probably a stack overflow
You can try ulimit -s unlimited
Otherwise, if you make the function properly tail recursive, that should fix things
Does it only fail in optimized?
Last updated: Jul 06 2025 at 12:14 UTC