helix-editor / helix

A post-modern modal text editor.
https://helix-editor.com
Mozilla Public License 2.0
33.94k stars 2.51k forks source link

Helix Fails to open .bash_history when symlinked to some other dir over /nix/store #12100

Open hakan-demirli opened 2 days ago

hakan-demirli commented 2 days ago

Summary

This only happens on some files that is symlinked over /nix/store. Helix cant open the file. Following hangs: hx .bash_history :o .bash_history

image

File permissions:

-rw-r--r--  1 USERNAME users 240201 Nov 21 00:18 .bash_history

Reproduction Steps

Helix log

No log entry is generated.

Platform

Linux

Terminal Emulator

kitty 0.37.0 created by Kovid Goyal

Installation Method

nixpkgs

Helix Version

helix 24.7 (101a74bf6edbbfdf9b0628a0bdbbc307ebe10ff2)

hakan-demirli commented 2 days ago

.bash_history is labeled as data by file command.

❯ file .bash_history 
.bash_history: data

I have added %PDF-1.2 to the first line and now it is seen as a pdf file:

❯ file  .bash_history 
.bash_history: PDF document, version 1.2

But still helix cant open it. Helix can open regular PDF files so I do not think the content of the file is the issue but somehow symlinking it over /nix/store is.

hakan-demirli commented 2 days ago

The issue is exclusive to the .bash_history. However, vim, nvim and vscode can open the file while helix cant.

the-mikedavis commented 2 days ago

I could imagine tree-sitter-bash might cause a hang but not much else. I also have symlinks for things in my ~ set to the nix store and I don't see the same behavior. If you move it to bash_history, open it and use :lang bash does that also cause a hang?

hakan-demirli commented 2 days ago

If you move it to bash_history, open it and use :lang bash does that also cause a hang?

No hangs.

I also deleted everything inside .bash_history to try again incase there is an illegal byte/data, however the hang problem still persists. I also created a new file deleted the old one and tried again to ensure there is no hardware or file system related corruption.

I think I have isolated the problem. It only hangs when it is symlinked to the location pointed by the $HISTFILE. If I change the $HISTFILE helix can open the previous .bash_history.

PS: Thank you for the quick response. I opened the issue just to document it and in-case anyone else encounters it. Since the workaround is just renaming the file modifying it and renaming it back it is not really a big problem for me.

the-mikedavis commented 2 days ago

If you're willing to get your hands dirty with building from source it would be interesting to see a run of cargo flamegraph while Helix hangs. That should hopefully show exactly what gets stuck looping.

hakan-demirli commented 2 days ago

Steps I have followed:

graphs.zip

flamegraph_2min

flamegraph_with_v

hakan-demirli commented 2 days ago

I have noticed that some function names were unknown hence I recompiled Helix with RUSTFLAGS = "-C debuginfo=2 -C opt-level=3";.

debug_graph.zip

flamegraph

hakan-demirli commented 2 days ago

I have also tried to get a flamegraph after helix hangs using:

❯ sudo rust-gdb -p 196881 GNU gdb (GDB) 15.2 Copyright (C) 2024 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: https://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/.

For help, type "help". Type "apropos word" to search for commands related to "word". Attaching to process 196881 [New LWP 196897] [New LWP 196896] [New LWP 196895] [New LWP 196894] [New LWP 196893] [New LWP 196892] [New LWP 196891] [New LWP 196890] [New LWP 196889] --Type for more, q to quit, c to continue without paging--c [New LWP 196888] [New LWP 196887] [New LWP 196886] [New LWP 196885] [New LWP 196884] [New LWP 196883] [New LWP 196882] [Thread debugging using libthread_db enabled] Using host libthread_db library "/nix/store/3bvxjkkmwlymr0fssczhgi39c3aj1l7i-glibc-2.40-36/lib/libthread_db.so.1". 0x00007f610dcd337f in write () from /nix/store/3bvxjkkmwlymr0fssczhgi39c3aj1l7i-glibc-2.40-36/lib/libc.so.6 warning: File "/nix/store/qv845jd8i7dg1vqscvg57w5fy3ri4cj5-rustc-1.74.0-x86_64-unknown-linux-gnu/lib/rustlib/etc/gdb_load_rust_pretty_printers.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/nix/store/s94fwp43xhzkvw8l8nqslskib99yifzi-gcc-13.3.0-lib:/nix/store/n6mfw0gspdgr9nh264b9hy1k3pv0mzir-rust-default-1.74.0/lib/rustlib/etc". To enable execution of this file add add-auto-load-safe-path /nix/store/qv845jd8i7dg1vqscvg57w5fy3ri4cj5-rustc-1.74.0-x86_64-unknown-linux-gnu/lib/rustlib/etc/gdb_load_rust_pretty_printers.py line to your configuration file "/root/.config/gdb/gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/root/.config/gdb/gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" (gdb) c Continuing.

Thread 1 ".hx-wrapped" received signal SIGINT, Interrupt. 0x00007f610dcd337f in write () from /nix/store/3bvxjkkmwlymr0fssczhgi39c3aj1l7i-glibc-2.40-36/lib/libc.so.6 (gdb) xit Undefined command: "xit". Try "help". (gdb) exit A debugging session is active.

Inferior 1 [process 196881] will be detached.

Quit anyway? (y or n) y Detaching from program: /nix/store/b6407pwpr4niin2sd5pslgrfxspj4nnh-helix-24.07-dev/bin/.hx-wrapped, process 196881 [Inferior 1 (process 196881) detached]