Searching root reboots my computer and corrupts my zsh history.

[cgag]

cd /; sudo ag "crash me please"

This consistently causes my laptop to reboot, and affected by my debian and void linux installs. It causes a reboot and zsh complains of a corrupted history, hopefully it's not corrputing anything else. It's been confirmed by the one other person I got to try it.

[ggreer]

Please note:

• The version of ag you're using
• Your operating system (the exact version)
• Your CPU architecture
• Whether you've tried grep -r or ack in the same way

I bet you could also narrow down the exact "file" that causes this. It's probably in /dev or /proc.

[clauseggers]

I’ve been encountering the exact same issue. My OpenSUSE Tumbleweed (VMWare Fusion image) crashes when I execute an ag search from the root. I’ve now done it twice, and both times it crashed the OS. First time it killed the installation and rendered it unrepairable. The second time it ‘only’ managed to have turned off all my Gnome extensions upon reboot, and have now changed from the Plymouth graphical boot-screen to a text boot-screen.

Some info: Linux suse 4.4.1-1-default #1 SMP PREEMPT Mon Feb 15 11:03:27 UTC 2016 (6398c2d) x86_64 x86_64 x86_64 GNU/Linux Distributor ID: openSUSE project Description: openSUSE Tumbleweed (20160223) (x86_64) Release: 20160223

4x Intel Xeon CPU X5365 @ 2.993GHz. 4GiB of RAM. 30GiB of harddrive ~50% used. One common BTRFS partition for OS and home folders. ZSH shell.

ag version 0.31.0 Features: +jit +lzma +zlib

I’ve attached a log of the latest episode: ag_log.txt I could seem like line 8 of the log cause the issue:

Feb 25 21:16:49 suse systemd[1]: proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 27937 (ag)
Feb 25 21:16:49 suse systemd[1]: Mounting Arbitrary Executable File Formats File System...

It starts with the ag command being executed, and ends with me forcing a reboot from VMware.

I have tried the same command with both grep and ack, but they work fine.

[HaleTom]

Not an ag issue: you're reading /dev/watchdog, which will restart the system: https://tuxdna.wordpress.com/2010/10/11/cat-devwatchdog-reboots-the-system/

[chipironcin]

Happens here as well, while trying ag "boom" /dev But I dont have any /dev/watchdog device NOTE: it happened inside a docker container running in privileged mode (that mounts /dev)

[chipironcin]

After some debug we were able to reproduce the issue executing as sudo/root the following command:

cat /dev/hpet

on an Amazon Linux VM running in AWS. So this is not an ag issue as pointed previously by @HaleTom (also note that grep does not trigger this issue)

---

Extra useful command that led me to that conclusion:

for f in $(ls /dev); do sleep 2; echo "ag in /dev/$f"; sudo ag -r "boom" /dev/$f; done

[ggreer]

Please try master now. I think https://github.com/ggreer/the_silver_searcher/commit/8639866dcc9d7848f11dd86832eb59ba4a36e978 has fixed the issue, but my linux machines don't have /dev/watchdog or /dev/hpet.

[chipironcin]

Hi @ggreer I am sorry but master haven't worked:

ubuntu@ip-172-31-14-210:~/the_silver_searcher$ ag "boom" /dev/hpet
ERR: Skipping /dev/hpet: Error opening file: Permission denied
ubuntu@ip-172-31-14-210:~/the_silver_searcher$ sudo ag "boom" /dev/hpet

I've checked I dont have SilverSearcher installed from repos and compiled latest master at ee56182. If anyone can also confirm it still doesn't work. You can just launch a server in AWS Cloud, cheap, fast and easy.

[jan-ruzicka]

Hi @chipironcin Can you verify what attributes does the /dev/hpet have? It should be a character device. The test of st_mode of the stat structure in the_silver_searcher/src/search.c is a suspect. It should discriminate against block devices and character devices.

[chipironcin]

crw------- 1 root root 10, 228 Jan 11 15:20 /dev/hpet

It is a character device.