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

[hakan-demirli]

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

File permissions:

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

Reproduction Steps

• Symlink the file using config.lib.file.mkOutOfStoreSymlink from nix
• Ensure the symlink chain is as follows: /home/USR/file(original file) -> /nix/store/hash/file -> /home/USR/somedir/file(the final symlink)
• Try to open the .bash_history file from any one of the file in the symlink chain including the original file.
• Observe that it hangs.

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 (101a74b)

[hakan-demirli]

.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]

• Helix can open it if I remove the leading dot: bash_history. No hangs.
  • Helix can still open it if I symlink this file over /nix/store.
• Helix can open it if I rename the file: .bash_dummy. No hangs.
  • Helix can still open it if I symlink this file over /nix/store.

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

[the-mikedavis]

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]

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]

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]

Steps I have followed:

• git clone https://github.com/helix-editor/helix
• cd helix
• direnv allow
• flamegraph -v -- hx /home/emre/.config/.bash_history
• Ctrl + C after 1/2 minutes since it hangs.
• flamegraph -- hx /home/emre/.config/.bash_history
• Ctrl + C after 1/2 minutes since it hangs.

graphs.zip

[hakan-demirli]

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

• flamegraph -v -- hx /home/emre/.config/.bash_history

debug_graph.zip

[hakan-demirli]

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

• flamegraph -v -p 196881 however it reported 0 events.
• perf top -p 196881 0 events reported.
• sudo strace -p 196881

strace: Process 196881 attached
write(11, "\5\242&+\256\301V\307+~y>\271\254\304\25\2aS\222\273\364\335'\324\305:\276\33aj\266"..., 92862^Cstrace: Process 196881 detached
 <detached ...>

• rust-gdb

❯ 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 <RET> 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]