GNU bug report logs -
#74159
Unexpected exit code of 0 when -q is set and close_stdout fails
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Fri, 1 Nov 2024 23:02:11 -0700
with message-id <1723a5e3-d1d0-46ab-9dbb-41394c91c1c3 <at> cs.ucla.edu>
and subject line Re: bug#74159: Unexpected exit code of 0 when -q is set and close_stdout fails
has caused the debbugs.gnu.org bug report #74159,
regarding Unexpected exit code of 0 when -q is set and close_stdout fails
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
74159: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=74159
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Hello,
I've encountered a particularly interesting bug in GNU grep yesterday while
hunting some issues with LibreOffice (if you're interested in the whole
post-mortem, it can be read here:
https://grsc.cz/blog/loffice-linux-issues/, but it's mostly not relevant
for this bug).
Whenever the `-q` option is used, grep can exit with a 0, even if no
match has been found and an error has been encountered. In particular,
when the `close_stdout` function is called and the `close` syscall
fails, grep exits with 0, even when it's not supposed to.
While reading the source code, I found out that when the `-q` option is
detected (grep.c:2697), the `exit_failure` variable is set to 0. This
causes any error, when not specially handled, to exit with 0, even
before any match is found. This is also true for the `close_stdout` libc
function, which hard exits using `_exit(exit_failure)` when the syscall
fails.
This, at first glance, (and pardon me if I'm wrong, I haven't looked
into the source code that deeply) seems to me as bad design, since it
makes the code prone to multiple such mistakes – where someone
inadvertently uses the `exit_failure` variable without realising it
makes the program return the wrong code. It would make much more sense
to me (and again, I don't know whether this is possible) to set the
`exit_failure` variable to 0 only *after* the first match is found,
preventing such issues altogether. It also makes more sense semantically
IMO, as the `-q` option states that errors are ignored only when a match
is found, not always.
As I feel this is more of a design decision than a straightforward fix,
I'm not sending a patch, but I'll be glad to assist any efforts to
fix this.
CC'd are my colleagues who helped discover the issue.
Regards,
Jan
[Message part 3 (message/rfc822, inline)]
[Message part 4 (text/plain, inline)]
On 2024-11-01 06:10, Jan Černohorský wrote:
> when the `-q` option is
> detected (grep.c:2697), the `exit_failure` variable is set to 0. This
> causes any error, when not specially handled, to exit with 0, even
> before any match is found.
Yes, that's a mistake. I can't reproduce your bug but I can see other
consequences of the mistake. Fixed in the attached patch (with a test
case that's unlike your problem); please give it a try.
That being said, the lower levels of your OS appear to be buggy, as
'close' should not fail with EACCES. I wouldn't be surprised if other
software breaks because of this issue. So I suggest also reporting a bug
to whoever maintains the NFS client code that you're using.
I'm boldly closing this bug report; we can reopen it if the patch
doesn't work for you.
[0001-grep-fix-q-suppression-of-diagnostics.patch (text/x-patch, attachment)]
This bug report was last modified 202 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.