Panic when encounters broken pipe

[cj]

Hi,

I am getting a panic with large directories when using a fzf.

Steps to reproduce:

• cd ~
• rg --files --no-ignore --hidden --follow --no-messages --glob "" | devicon-lookup | grep

cj-osx ~/apps
0:33 ◯ : rg --files --no-ignore --hidden --follow --no-messages --glob "" | devicon-lookup | grep
usage: grep [-abcDEFGHhIiJLlmnOoqRSsUVvwxZ] [-A num] [-B num] [-C[num]]
        [-e pattern] [-f file] [--binary-files=value] [--color=when]
        [--context[=num]] [--directories=action] [--label] [--line-buffered]
        [--null] [pattern] [file ...]
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', libstd/io/stdio.rs:700:9

Please take a look a this response: BurntSushi/ripgrep#22 (comment)

[coreyja]

Thanks for reporting this issue! I actually think I've run into this same error in my vim setup.

I'll try to look into this, but would definitely appreciate any help on solving this! I assume it is mostly due to the fairly naive way we are interacting with both stdin and stdout

[coreyja]

Bug Report copied from BurntSushi/ripgrep#22 (comment):

@cj Thanks for the report, but that's unfortunately not a valid reproduction. The panic is coming from devicon-lookup, not ripgrep.
Compare:

$ RUST_BACKTRACE=1 rg --files --no-ignore --hidden --follow --no-messages --glob '' | devicon-lookup | grep
Usage: grep [OPTION]... PATTERNS [FILE]...
Try 'grep --help' for more information.
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', src/libstd/io/stdio.rs:743:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

with

$ rg --files --no-ignore --hidden --follow --no-messages --glob '' | RUST_BACKTRACE=1 devicon-lookup | grep
Usage: grep [OPTION]... PATTERNS [FILE]...
Try 'grep --help' for more information.
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', src/libstd/io/stdio.rs:743:9
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:197
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:474
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:381
   6: std::panicking::begin_panic_fmt
             at src/libstd/panicking.rs:336
   7: std::io::stdio::_print
             at src/libstd/io/stdio.rs:743
             at src/libstd/io/stdio.rs:753
   8: devicon_lookup::main
   9: std::rt::lang_start::{{closure}}
  10: std::panicking::try::do_call
             at src/libstd/rt.rs:49
             at src/libstd/panicking.rs:293
  11: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:87
  12: std::rt::lang_start_internal
             at src/libstd/panicking.rs:272
             at src/libstd/panic.rs:388
             at src/libstd/rt.rs:48
  13: main
  14: __libc_start_main
  15: _start

If the bug were in ripgrep, then the first example would have shown a backtrace. > In the second example, you can see at 8 that the panic passes through devicon_lookup::main.

[coreyja]

This actually appears to happen in small directories as well. For example from this project directory even this causes the panic

ls | devicon-lookup | echo

Edit: While this does fail, I realized piping to echo doesn't really do what I meant to and the above works with cat. Anyways, more data points

[coreyja]

Being Fixed in #36