Closed VisenDev closed 6 days ago
With more testing, I have discovered that flow will not immediately crash if I start it without an initial file argument. However it does crash as soon as I attempt to open src/tui/tui.zig
- Perhaps there is a LSP related issue?
This issue seems related https://github.com/neurocyte/flow/issues/41
Following on from that issue - I have now tried running the command using the zig
wrapper script, but that does not seem to work.
Update:
Running zig build -Doptimize=ReleaseFast -Dcpu=baseline
fixes the illegal instruction crash... but now the editor won't quit no matter which mode I am in or which way I try to quit.... hmm.....
And pkill
ing the process breakings my terminal again rather than just quitting flow
but now the editor won't quit no matter which mode I am in or which way I try to quit.... hmm.....
It sounds like something may have hung internally. Did you try quitting with the Force quit without saving
command? That should always work.
If you can reproduce a situation where flow refuses to exit, please run flow with flow -t 5
and submit the trace.log
of the flow session that hung.
Make sure you're running the latest flow master.
I've added a note about cpu=baseline to the readme.
I wasn't able to reproduce the failure to quit, however I am still getting segmentation faults - possibly zls related
Flow git was updated to latest master and built with zig build -Doptimize=ReleaseFast -Dcpu=baseline
Edit: And when building usingzig build -Doptimize=ReleaseSafe -Dcpu=baseline
, the program still crashes when loading src/tui/tui.zig
, but this time because of an illegal instruction
For regular crashes I need a back trace.
Anothet thought. Perhaps -Dcpu=baseline
is not enough to stop zig from mis-detecting your cpu. Please try building with the full target like when cross compiling. See cross compilation in README.md
.
Anothet thought. Perhaps
-Dcpu=baseline
is not enough to stop zig from mis-detecting your cpu. Please try building with the full target like when cross compiling. See cross compilation inREADME.md
.
This has not fixed the crashes unfortunately
For regular crashes I need a back trace.
Could you elaborate on how to produce this? I assume you mean a lldb/gdb backtrace? As I stated in my original issue, I haven't been able to figure out how to produce one of those because the program won't start inside of lldb due to SIGTTOU
Run flow with flow --debug-wait
and attach to it from another terminal with gdb or lldb. Then start flow with a keypress when the debugger is attached and continued.
This should be fixed with 048ea5f086550bcdf8e4eca3794e60c384a5b814
Hardware: 2019 Macbook Pro OS: macOS 13.2 ISA: x86_64 Terminal: Ghostty master
Steps to replicate
Then run
./zig-out/bin/flow src/tui/tui.zig
The program then crashes and breaks my terminal
I attempted to debug this in lldb, but the zig stack probe function is segfaulting.
I've seen this happen before doing certain types of json parsing (see https://github.com/ziglang/zig/issues/17195). So I tried deleting
~/.config/flow/config.json
Doing this fixes the segfault, but the program then crashes for another reason. (I believe it has to do with conflicts over capturing the tty). Because of this, I can't get good details on why exactly the original crash happens
The program also crashes in other optimize mods, but for other reasons.
ReleaseFast
seems to crash due to a segmentation fault