While implementing day 4, I seem to have stumbled upon a bug. First, it was this, but after removing a few conditionals I am stuck with the following error message.
> roc run problem4.roc
🔨 Rebuilding platform...
roc_app_binary(26947,0x1185df600) malloc: *** error for object 0x7f9f61720790: pointer being freed was not allocated
roc_app_binary(26947,0x1185df600) malloc: *** set a breakpoint in malloc_error_break to debug
fish: Job 1, 'roc run problem4.roc' terminated by signal SIGABRT (Abort)
The code causing this is here. Sorry, it's not really a minimal example, but I'm not sure what how to reduce it^^
Can you share your Helpers
file?
Interesting, it looks to be a double free somehow.
Hmm, yeah. I am not sure exactly what is going on from base debugging. Probably one of our builtins is freeing something it shouldn't or we aren't emitting a refcount increment when we should be. Can you file a bug? Minimal repro would be great, but it is fine if that is too hard to minimize. I might take a look on my linux machine later. Valgrind or gdb should give me a clearer idea than lldb on macos.
I'll try a bit to isolate a minimal example, but failing that I'll just create an issue with the current code.
What I've noticed so far: When I do only the getWinnerScore
or the getLoserScore
calculation and substitute the other with a hardcoded value the code does not crash
or it's intermittent and only calling the referenced functions once instead of twice increases the chance of the program running through... fun
Yeah, this is definitely the case of Roc wrongly freeing something and then accessing it over and over again after it is freed.
It will succeed on linux, but that is only because nothing happens to overwrite the freed memory and linux allows you to access freed memory with no complaints unlike machos. When run with valgrind, it has thousands of reeds to the same already freed chunk of data.
Last updated: Jul 06 2025 at 12:14 UTC