#Unreachable OOM?

1 messages ยท Page 1 of 1 (latest)

novel axle
#

So while working on Day 12 from advent of code 2022, I ran off this cliff:

$ zig version
0.10.0-dev.3880+e2bb92b2e2

$ zig run day12/main.zig <day12/input.txt 
thread 157707 panic: reached unreachable code
Unable to dump stack trace: OutOfMemory
Aborted (core dumped)

Now, tbf there was one time when it actually printed a stack trace (same code, same input , the only thing I was changing was re-running in a new bash shell to have a more readily copy-paste-able output to report here), and that stack trace filled my terminal with many gpa leak detection traces. But every other time I've ran it, I get the OutOfMemory error and no stack trace... at a guess, gpa's leak detection has some timing or other non-determinism effects in it that made it catch slightly less leaks that one time?

Barring that fluke, any advice on debugging this situation?

Full code here https://github.com/jcorbin/aoc/blob/2022/day12/main.zig as of commit 152351e ( fwiw it's my first time trying to implement a PriorityQueue-driven search algorithm in zig, so no surprise I sprung a few leaks ๐Ÿ˜ )

#

actually, I may have been confused: the gpa leak reports may have been from me accidentally running zig test day12/main.zig when I meant to re-run it on input, which would explain why I wasn't able to reproduce... at any rate, maybe there's some value to investigating why the main program crashed in an untraceable manner here?

wraith thicket
#

Could you either go to 0.10 release or update to nightly which is 0.11

#

๐Ÿ˜„

#

Abut the issue, let me read the code lol

novel axle
#

I think that should be latest, I installed the zig-git package from AUR today ๐Ÿ˜‰

wraith thicket
#

Dies in Arch being bad with zig

#

ewww

novel axle
#

the package version just calls itself 0.10 plus a bunch of commits and a git sha?

wraith thicket
#

@slim crag Please can you update that ๐Ÿ˜„

wraith thicket
#

๐Ÿ˜„

#

Was master

#

Zig master / nightly is marked as: <version>-dev.<commits since last release>+<Current Commit short mode>

novel axle
#

version wise, I'd prefer to be on the last 0.10.x release, not git... but in arch at least, the zls version just jumped to 0.10, while the non-git zig package is still stuck back on 0.9... so I jumped on git version today hehe

wraith thicket
#

Yeah, yeah, arch being bad with deps

#

oh wait I think I confused fedora package mantainer

#

oh well

#

@novel axle About your error, I suggest using GDB or LLDB and going step by step rn

#

and see where you could've reached this unreachable code

novel axle
#

gotcha, I'll hafta grow that skill then, coming from a Go / other non-C languages background, I've yet to get-good at gdb or lldb ๐Ÿ˜

wraith thicket
#

If you use vscode, codelldb is good enough

#

tho it has a few mistakes with zig and showing memory

#

shall do enough for you stepping tru code

novel axle
#

I have similar questions around profiling, where I'm very used to how to do it in Go and other high level things, and suspect with zig there's some "oh yeah, just use this tool that Every C Developer already knows about ;-)"

wraith thicket
#

Eh, we are less strict with that rn

#

we have no official tooling for that

dreamy wedge
#

perf is the tool :)

wraith thicket
#

a lot of programs tool with perf

#

others with tracy

novel axle
#

alas, I'm a recalcitrant neovim user, debugging is the one thing it's sort of not great at yet ๐Ÿ˜‰

wraith thicket
#

lol

#

I use vscode as a debugging frontend

#

only thing it excels at

#

I hate gdb/lldb cli lol

novel axle
#

good idea, I may install it for that tomorrow, I'm about at the end of my "awake need to sleep now" rope for the day tho

dreamy wedge
#

callgrind is also a good profiler, though it makes your code run like 1000x slower

wraith thicket
#

yep

dreamy wedge
#

It's extremely accurate though, so it's worth it when you need it

wraith thicket
#

std.testing.checkAllAllocationFailures also is your friend checking for hidden leak paths

novel axle
#

well the test is currently flagging the "here's what allocated it" part, now I need to deduce "why wasn't it free-ed?" a task for tomorrow me after some sleep ๐Ÿ™‚

wraith thicket
#

no problems

rancid solstice
#

That looks a lot like a compiler crash. Try using zig build-exe instead to double-check that. If it crashes, then it definitely is.

novel axle
#

nah have done that already, but here's a paste fwiw:

$ zig build-exe ./day12/main.zig 

$ ls -l main
-rwxr-xr-x 1 jcorbin jcorbin 1.4M 2022-12-13 08:31 main*

$ ./main <day12/input.txt 
thread 159401 panic: reached unreachable code
Unable to dump stack trace: OutOfMemory
Aborted (core dumped)

looking into that coredump now ; TIL systemd-coredump ... it really is the future

#

wow this is nice, auto collects and index cores with a ctl command on top... way better than "lol we left you a file in cwd that gets overwritten next tiem... glhf!":

$ coredumpctl | tail
Mon 2022-12-12 23:44:59 EST 155828 1000 1000 SIGABRT present  /home/jcorbin/.cache/zig/o/9600a8d0292c8c241e65eb4ccc3e2cc0/main                        173.4K
Mon 2022-12-12 23:46:06 EST 156024 1000 1000 SIGABRT present  /home/jcorbin/.cache/zig/o/9600a8d0292c8c241e65eb4ccc3e2cc0/main                        170.8K
Mon 2022-12-12 23:47:01 EST 156155 1000 1000 SIGABRT present  /home/jcorbin/.cache/zig/o/9600a8d0292c8c241e65eb4ccc3e2cc0/main                        171.6K
Mon 2022-12-12 23:47:37 EST 156255 1000 1000 SIGABRT present  /home/jcorbin/.cache/zig/o/9600a8d0292c8c241e65eb4ccc3e2cc0/main                        169.8K
Mon 2022-12-12 23:49:13 EST 156415 1000 1000 SIGABRT present  /home/jcorbin/.cache/zig/o/9600a8d0292c8c241e65eb4ccc3e2cc0/main                        172.3K
Mon 2022-12-12 23:51:24 EST 157300 1000 1000 SIGABRT present  /home/jcorbin/.cache/zig/o/9600a8d0292c8c241e65eb4ccc3e2cc0/main                        170.7K
Mon 2022-12-12 23:52:24 EST 157618 1000 1000 SIGABRT present  /home/jcorbin/aoc/main                                                                  170.1K
Mon 2022-12-12 23:52:53 EST 157675 1000 1000 SIGABRT present  /home/jcorbin/aoc/main                                                                  171.9K
Mon 2022-12-12 23:53:41 EST 157707 1000 1000 SIGABRT present  /home/jcorbin/.cache/zig/o/9600a8d0292c8c241e65eb4ccc3e2cc0/main                        171.0K
Tue 2022-12-13 08:31:41 EST 159401 1000 1000 SIGABRT present  /home/jcorbin/aoc/main                                                                  170.6K

#

right so here's the backtrace then:

$ coredumpctl debug
...
(gdb) bt
#0  0x000000000025607e in os.linux.x86_64.syscall4 ()
    at /usr/lib/zig/std/os/linux/x86_64.zig:57
#1  0x000000000024d462 in os.linux.sigprocmask () at /usr/lib/zig/std/os/linux.zig:1084
#2  0x000000000024096d in os.sigprocmask () at /usr/lib/zig/std/os.zig:5503
#3  0x00000000002408f1 in os.raise () at /usr/lib/zig/std/os.zig:526
#4  0x000000000021cfe4 in os.abort () at /usr/lib/zig/std/os.zig:463
#5  0x0000000000214365 in debug.panicImpl () at /usr/lib/zig/std/debug.zig:386
#6  0x0000000000213a1b in builtin.default_panic () at /usr/lib/zig/std/builtin.zig:846
#7  0x000000000021ed09 in os.munmap () at /usr/lib/zig/std/os.zig:4401
#8  0x000000000021f013 in heap.PageAllocator.free () at /usr/lib/zig/std/heap.zig:418
#9  0x0000000000216688 in mem.Allocator.rawFree () at /usr/lib/zig/std/mem/Allocator.zig:177
#10 mem.Allocator.free__anon_4103 () at /usr/lib/zig/std/mem/Allocator.zig:505
#11 0x00000000002176d4 in multi_array_list.MultiArrayList(main.Solution.Data__struct_4032).dei
nit () at /usr/lib/zig/std/multi_array_list.zig:113
#12 0x000000000021a01c in main.Solution.deinit () at main.zig:332
#13 0x0000000000219627 in main.run__anon_3712 () at main.zig:473
#14 0x000000000021a929 in main.main () at main.zig:587
#

which looks like the .NOMEM branch here:

#

hmm I think this is What You Get โ„ข๏ธ if you pass the bare heap allocator to a multi array list, rather than the hinted at requirement that it needs a gpa instance... let's see if that changes anything...

#

cool cool, now it doesn't crash, but it's also on track eat all of my system memory and hasn't halted yet, good times!

wraith thicket
#

oh no

#

lol

novel axle
#

as someone used to way higher level languages than zig, this has got to be the slowest leak I've made yet, usually they explode and hit the oom killer long before I can casually watch them tick along in top

wraith thicket
#

is fun lol

novel axle
#

// for an offline / batch processing program that is, slow leaks are fairly easy to do in a long running server no matter the language ๐Ÿ˜

rancid solstice
novel axle
#

hmm, well swapping out for gpa made it not crash ; I'd presume that gpa would also have safe guards against being asked to free memory from another allocator?

rancid solstice
#

And the page allocator won't be robust against that, AFAIK.

novel axle
#

yes, that's the failing trace, where I wasn't using GPA ๐Ÿ˜‰

#

nah it was

#

this was a check inside os.munmap itself as screenshotted above

#

so yes the heap page allocator didnt't catch it, munmap did

rancid solstice