Stack trace on panic loops forever
Zig Version
0.12.0-dev.1751+7fbbeae617
Steps to Reproduce and Observed Behavior
Switch to this branch if not merged yet: #18262
(note that the branch fixes issues with the build system that have nothing to do with this bug report)
git clone https://github.com/kristoff-it/zine.git
cd zine
git switch looping-trace
cd sample_website
Running Zig build at this point causes on my machine to hit an assertion in my code, which starts printing a stacktrace stuck on the same frame forever.
thread 421506 panic: reached unreachable code
/home/kristoff/zig/lib/std/debug.zig:342:14: 0x250f43 in assert (super)
if (!ok) unreachable; // assertion failure
^
/home/kristoff/zig/lib/std/debug.zig:342:14: 0x250f43 in assert (super)
if (!ok) unreachable; // assertion failure
^
/home/kristoff/zig/lib/std/debug.zig:342:14: 0x250f43 in assert (super)
if (!ok) unreachable; // assertion failure
^
/home/kristoff/zig/lib/std/debug.zig:342:14: 0x250f43 in assert (super)
if (!ok) unreachable; // assertion failure
^
/home/kristoff/zig/lib/std/debug.zig:342:14: 0x250f43 in assert (super)
if (!ok) unreachable; // assertion failure
My machine is a NixOS VM running on aarch64 (Mac Mini M2). In some other circumstances the stack trace fails to print completely.
Expected Behavior
The stack trace should end at some point.
This happens to me under a similar setup: NixOS in a VM on aarch64 Mac hardware. And another contributor under the same setup can confirm this also happening.
This makes developing and testing very difficult because not only do crashes do this but test failures also trigger this, so we can't even see what tests fail. We're resorting to printf-style development which is less than ideal. 😄
This happened to me starting with 0.13 but is still happening with 0.14.
EDIT: To reproduce:
- Clone Ghostty: https://github.com/ghostty-org/ghostty
- Add a
if (true) @panic("OW");at the start ofmaininsrc/main_ghostty.zig zig build run
(On aarch64-linux on Mac hardware, not sure if a VM is required but we've only reproduced in a VM thus far, haven't tried bare metal)
I have a Draft PR that might happen to band-aid this bug: https://github.com/ziglang/zig/pull/23927 It puts an iteration limit on the std.debug stack trace dumping calls. The PR is currently a Draft because getting the expanded tests to pass everywhere might take me a while. I'm pretty confident in the loop-prevention fix (you can cherry-pick just that commit if you want to try it out).
Fixing the cause of the looping is probably also worth fixing, but I don't have ideas on how to accomplish that. :)
Resolved by b64535e3c8770db9bf314fc14d1b2b276b864f72