Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Panic when piping output to head #60

Open
mulark opened this issue Mar 30, 2022 · 3 comments · May be fixed by #62
Open

Panic when piping output to head #60

mulark opened this issue Mar 30, 2022 · 3 comments · May be fixed by #62
Labels
bug Something isn't working

Comments

@mulark
Copy link
Collaborator

mulark commented Mar 30, 2022

sudo ./target/debug/dmidecode | head
# dmidecode-rs 0.2.0
Getting SMBIOS data from sysfs.
SMBIOS 3.2.0 present.
Table at 0x000E8D60.

Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
        Vendor: American Megatrends Inc.
        Version: F6b
        Release Date: 09/17/2019
thread 'main' panicked at 'failed printing to stdout: Broken pipe (os error 32)', library/std/src/io/stdio.rs:935:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
@mulark mulark added the bug Something isn't working label Mar 30, 2022
@mulark
Copy link
Collaborator Author

mulark commented Mar 30, 2022

rust-lang/rust#46016

@jrgerber
Copy link
Owner

rust-lang/rust#46016

Interesting. Does this reproduce with head every time for you? I was just reading the discussion and noted these responses which sound simple enough?
"Until someone implements and merges unignore_sigpipe(), your best bet will be to use the write!() macro instead of the print*!() family of macros, and then handle errors appropriately."

write! isn't hard: see here for one example of how to use it in production. Note that literally the only difference as far as the app is concerned is the gratuitous use of ? to handle potential errors.

@mulark
Copy link
Collaborator Author

mulark commented Jun 19, 2022

A potential alternative is to remove the sigpipe handler using libc, which is already a part of our dependency tree.

    unsafe {
        libc::signal(libc::SIGPIPE, libc::SIG_DFL);
    }

@mulark mulark linked a pull request Jun 21, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants