What version of ripgrep are you using?
ripgrep 0.8.1 (rev ab64da73ab)
-SIMD -AVX
What operating system are you using ripgrep on?
> uname -s -r -v -m -p -i -o
Linux 4.16.7-1-ARCH #1 SMP PREEMPT Wed May 2 21:12:36 UTC 2018 x86_64 unknown unknown GNU/Linux
Describe the bug.
Even if it does not seem like a good idea in general to search the whole file system without excluding special folders like /proc (see also #311: "TL;DR is: don't search /proc"), I think that users will attempt to do so.
We recently tracked down one specific reproducible state which causes the ignore crate to hang while traversing /proc (see sharkdp/fd#288 for more details). The same bug can be reproduced with rg --files.
If this is a bug, what are the steps to reproduce the behavior?
-
Make sure that there are no zombie processes on your system (ps -ef | rg '<defunct>')
-
Run rg --files > /dev/null 2>&1 inside /proc. Everything should work fine (process exits after a few seconds).
-
Create a zombie process on purpose
a. Copy the code from https://stackoverflow.com/a/25228579/704831 into a file called zombie.c
b. Compile it gcc -o zombie zombie.c
c. Run it: ./zombie
-
Run rg --files > /dev/null 2>&1 inside /proc again. This seems to hang indefinitely.
-
Get the PID of the zombie process via ps -ef | rg '<defunct>'. Call it $PID.
-
Run rg --glob "\!$PID" --files > /dev/null 2>&1. This should work fine, indicating that the directory traversal hangs in /proc/$PID.
If this is a bug, what is the actual behavior?
rg --files hangs indefinitely inside the /proc folder.
If this is a bug, what is the expected behavior?
rg --files traverses the /proc folder in finite time.
Note: find, for example, does not seem to have this problem and finishes in finite time even in the presence of zombie processes.
What version of ripgrep are you using?
What operating system are you using ripgrep on?
Describe the bug.
Even if it does not seem like a good idea in general to search the whole file system without excluding special folders like
/proc(see also #311: "TL;DR is: don't search /proc"), I think that users will attempt to do so.We recently tracked down one specific reproducible state which causes the
ignorecrate to hang while traversing/proc(see sharkdp/fd#288 for more details). The same bug can be reproduced withrg --files.If this is a bug, what are the steps to reproduce the behavior?
Make sure that there are no zombie processes on your system (
ps -ef | rg '<defunct>')Run
rg --files > /dev/null 2>&1inside/proc. Everything should work fine (process exits after a few seconds).Create a zombie process on purpose
a. Copy the code from https://stackoverflow.com/a/25228579/704831 into a file called
zombie.cb. Compile it
gcc -o zombie zombie.cc. Run it:
./zombieRun
rg --files > /dev/null 2>&1inside/procagain. This seems to hang indefinitely.Get the PID of the zombie process via
ps -ef | rg '<defunct>'. Call it$PID.Run
rg --glob "\!$PID" --files > /dev/null 2>&1. This should work fine, indicating that the directory traversal hangs in/proc/$PID.If this is a bug, what is the actual behavior?
rg --fileshangs indefinitely inside the/procfolder.If this is a bug, what is the expected behavior?
rg --filestraverses the/procfolder in finite time.Note:
find, for example, does not seem to have this problem and finishes in finite time even in the presence of zombie processes.