Jared Ramirez (Dec 20 2024 at 19:40): Jared Ramirez (Dec 20 2024 at 19:40):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
Jared Ramirez (Dec 20 2024 at 19:49):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 :)
Anton (Dec 20 2024 at 19:54):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?
Jared Ramirez (Dec 20 2024 at 20:11):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:
Brendan Hansknecht (Dec 20 2024 at 21:20):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
Brendan Hansknecht (Dec 20 2024 at 21:22):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
Brendan Hansknecht (Dec 20 2024 at 21:23):You can try ulimit -s unlimited
Brendan Hansknecht (Dec 20 2024 at 21:23):Otherwise, if you make the function properly tail recursive, that should fix things
Brendan Hansknecht (Dec 20 2024 at 21:35):Does it only fail in optimized?
Last updated: Jul 26 2025 at 12:14 UTC