From unknown Mon Jun 23 02:25:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74159: Unexpected exit code of 0 when -q is set and close_stdout fails Resent-From: Jan =?UTF-8?Q?=C4=8Cernohorsk=C3=BD?= Original-Sender: "Debbugs-submit" Resent-CC: bug-grep@gnu.org Resent-Date: Fri, 01 Nov 2024 13:22:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 74159 X-GNU-PR-Package: grep X-GNU-PR-Keywords: To: 74159@debbugs.gnu.org Cc: wizards@kam.mff.cuni.cz X-Debbugs-Original-To: bug-grep@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.17304672772793 (code B ref -1); Fri, 01 Nov 2024 13:22:04 +0000 Received: (at submit) by debbugs.gnu.org; 1 Nov 2024 13:21:17 +0000 Received: from localhost ([127.0.0.1]:49455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6raW-0000iu-2Y for submit@debbugs.gnu.org; Fri, 01 Nov 2024 09:21:17 -0400 Received: from lists.gnu.org ([209.51.188.17]:48982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6rQf-0000Oe-06 for submit@debbugs.gnu.org; Fri, 01 Nov 2024 09:11:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t6rQX-0003JY-Ev for bug-grep@gnu.org; Fri, 01 Nov 2024 09:10:59 -0400 Received: from nikam.ms.mff.cuni.cz ([195.113.20.16]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t6rQU-0004ke-BP for bug-grep@gnu.org; Fri, 01 Nov 2024 09:10:57 -0400 Received: from kam.mff.cuni.cz (cucumber.kam.mff.cuni.cz [IPv6:2001:718:1e03:810::a2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: jan) by nikam.ms.mff.cuni.cz (Postfix) with ESMTPSA id C6897288C69; Fri, 1 Nov 2024 14:10:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kam.mff.cuni.cz; s=gen1; t=1730466644; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=B3SDj3qBv0ug1WOU8QKFf+uMsfJWhQ4lejmhdez9Kk0=; b=VtcdMvvbM+ZBAYfxTgp0j+9U0Iu3WVxsc8AjTKQMGs3BqnvSMl0CKgiULAK79jUAhL2q5b VbpudDo8NL7omYa46ZYYvIr2ikGxyH2aS65Sx7N/JH02F/FNpjDQHc7vx2nWTdI9qXvVHu ItiH+lGHUehOCyB4J6HMZnSQoLGRKJc= Date: Fri, 1 Nov 2024 14:10:43 +0100 From: Jan =?UTF-8?Q?=C4=8Cernohorsk=C3=BD?= Message-ID: <20241101131043.453ohkw53kvwf6v5@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=195.113.20.16; envelope-from=jan@kam.mff.cuni.cz; helo=nikam.ms.mff.cuni.cz X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Mailman-Approved-At: Fri, 01 Nov 2024 09:21:12 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) 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 From unknown Mon Jun 23 02:25:14 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Jan =?UTF-8?Q?=C4=8Cernohorsk=C3=BD?= Subject: bug#74159: closed (Re: bug#74159: Unexpected exit code of 0 when -q is set and close_stdout fails) Message-ID: References: <1723a5e3-d1d0-46ab-9dbb-41394c91c1c3@cs.ucla.edu> <20241101131043.453ohkw53kvwf6v5@kam.mff.cuni.cz> X-Gnu-PR-Message: they-closed 74159 X-Gnu-PR-Package: grep Reply-To: 74159@debbugs.gnu.org Date: Sat, 02 Nov 2024 06:03:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1730527382-24331-1" This is a multi-part message in MIME format... ------------=_1730527382-24331-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #74159: Unexpected exit code of 0 when -q is set and close_stdout fails which was filed against the grep package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 74159@debbugs.gnu.org. --=20 74159: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D74159 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1730527382-24331-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 74159-done) by debbugs.gnu.org; 2 Nov 2024 06:02:22 +0000 Received: from localhost ([127.0.0.1]:52896 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t77DJ-0006Jq-V0 for submit@debbugs.gnu.org; Sat, 02 Nov 2024 02:02:22 -0400 Received: from mail.cs.ucla.edu ([131.179.128.66]:44722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t77DG-0006Ji-Pe for 74159-done@debbugs.gnu.org; Sat, 02 Nov 2024 02:02:20 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id A66FA3C011BC5; Fri, 1 Nov 2024 23:02:12 -0700 (PDT) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id UPt1aScfCVEO; Fri, 1 Nov 2024 23:02:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 499C63C011BD7; Fri, 1 Nov 2024 23:02:12 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 499C63C011BD7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1730527332; bh=Wx2HCzqfwAzlWqlBLvElGyhbSDXTfcEW6Zs2Z7YaM7E=; h=Message-ID:Date:MIME-Version:To:From; b=EU2W4KewkstqwslkLDF3QuwMatQ1dGYyeKihpPA5YdvTETfyB8ktTyb/N1Dk37HhB 0RcnSVgslrcO7GQbqvOgvhJehndJhqefey008MswFHF4NVOqN3tLvB8GJaN9AQ65Zz wHo7Gn+yzrfC6YyvmgY9a1W7YtIekKzNG6vcvkw3TfsCIKyMg4bvnWufv8aM2mQZaS T6B/hknf9pEYuLSIIUcSTGxtHHWoLQWnePb/pccQlwHTNLmYxGlw/eVEm5RcbRNw/j 7ecdMw5LlPV+75Fv8D7aWEPk+U7euqEZA+OpYNWIYnpSb6lvYSJK+ikWU+xOdSte2d sEYKZM3wPgnew== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id SyztsgwssgAt; Fri, 1 Nov 2024 23:02:12 -0700 (PDT) Received: from [192.168.254.12] (unknown [47.150.137.250]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 291953C011BC5; Fri, 1 Nov 2024 23:02:12 -0700 (PDT) Content-Type: multipart/mixed; boundary="------------UYIMtPfU47posZHPLu0IhYEN" Message-ID: <1723a5e3-d1d0-46ab-9dbb-41394c91c1c3@cs.ucla.edu> Date: Fri, 1 Nov 2024 23:02:11 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#74159: Unexpected exit code of 0 when -q is set and close_stdout fails To: =?UTF-8?B?SmFuIMSMZXJub2hvcnNrw70=?= References: <20241101131043.453ohkw53kvwf6v5@kam.mff.cuni.cz> Content-Language: en-US From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: <20241101131043.453ohkw53kvwf6v5@kam.mff.cuni.cz> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 74159-done Cc: 74159-done@debbugs.gnu.org, wizards@kam.mff.cuni.cz X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) This is a multi-part message in MIME format. --------------UYIMtPfU47posZHPLu0IhYEN Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2024-11-01 06:10, Jan =C4=8Cernohorsk=C3=BD wrote: > when the `-q` option is=20 > detected (grep.c:2697), the `exit_failure` variable is set to 0. This=20 > causes any error, when not specially handled, to exit with 0, even=20 > before any match is found. Yes, that's a mistake. I can't reproduce your bug but I can see other=20 consequences of the mistake. Fixed in the attached patch (with a test=20 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=20 'close' should not fail with EACCES. I wouldn't be surprised if other=20 software breaks because of this issue. So I suggest also reporting a bug=20 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=20 doesn't work for you. --------------UYIMtPfU47posZHPLu0IhYEN Content-Type: text/x-patch; charset=UTF-8; name="0001-grep-fix-q-suppression-of-diagnostics.patch" Content-Disposition: attachment; filename="0001-grep-fix-q-suppression-of-diagnostics.patch" Content-Transfer-Encoding: base64 RnJvbSBmY2UyOGM0YTVlYWM4OWUxM2E5OTJmYjU0Y2U0YzBlNzUwMmY0NDE1IE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBQYXVsIEVnZ2VydCA8ZWdnZXJ0QGNzLnVjbGEuZWR1 PgpEYXRlOiBGcmksIDEgTm92IDIwMjQgMjI6Mzg6NTQgLTA3MDAKU3ViamVjdDogW1BBVENI XSBncmVwOiBmaXggLXEgc3VwcHJlc3Npb24gb2YgZGlhZ25vc3RpY3MKTUlNRS1WZXJzaW9u OiAxLjAKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PVVURi04CkNvbnRlbnQt VHJhbnNmZXItRW5jb2Rpbmc6IDhiaXQKClByb2JsZW0gcmVwb3J0ZWQgYnkgSmFuIMSMZXJu b2hvcnNrw70gKEJ1ZyM3NDE1OSkuCiogc3JjL2dyZXAuYyAoZ3JlcGJ1Zik6IElmIGV4aXRf b25fbWF0Y2gsIHNldCBzdGRvdXRfZXJybm8gdG8KYXZvaWQgc2NyZXd1cHMgb24gYnVnZ3kg T1Nlcy4gIEFsc28sIGlnbm9yZSBlcnJzZWVuIHNpbmNlIGl0CmNhbm5vdCBiZSB0cnVlIGhl cmUuCihtYWluKTogRG8gbm90IGNsZWFyIGV4aXRfZmFpbHVyZSBpZiAtcSBpcyBnaXZlbiwg YXMgZXhpdCBzdGF0dXMKc2hvdWxkIGJlIHplcm8gb25seSBpZiBhbiBpbnB1dCBsaW5lIGlz IHNlbGVjdGVkLgoqIHRlc3RzL3dyaXRlLWVycm9yLW1zZzogQ2hlY2sgdGhhdCAtcSBzdXBw cmVzc2VzIGRpYWdub3N0aWNzCm9mIG91dHB1dCBlcnJvcnMgb25seSBpZiBhIG1hdGNoIGlz IGZvdW5kLgotLS0KIHNyYy9ncmVwLmMgICAgICAgICAgICB8IDEyICsrKysrKysrKy0tLQog dGVzdHMvd3JpdGUtZXJyb3ItbXNnIHwgMTEgKysrKysrKystLS0KIDIgZmlsZXMgY2hhbmdl ZCwgMTcgaW5zZXJ0aW9ucygrKSwgNiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zcmMv Z3JlcC5jIGIvc3JjL2dyZXAuYwppbmRleCA5MTJiY2U0Li4wNDI0MzNhIDEwMDY0NAotLS0g YS9zcmMvZ3JlcC5jCisrKyBiL3NyYy9ncmVwLmMKQEAgLTQzNiw3ICs0MzYsMTEgQEAgc3Rh dGljIGNvbnN0IHN0cnVjdCBjb2xvcl9jYXAgY29sb3JfZGljdFtdID0KICAgICB7IG51bGxw dHIsIG51bGxwdHIsICAgICAgICAgICAgbnVsbHB0ciB9CiAgIH07CiAKLS8qIFNhdmVkIGVy cm5vIHZhbHVlIGZyb20gZmFpbGVkIG91dHB1dCBmdW5jdGlvbnMgb24gc3Rkb3V0LiAgKi8K Ky8qIFNhdmVkIGVycm5vIHZhbHVlIGZyb20gZmFpbGVkIG91dHB1dCBmdW5jdGlvbnMgb24g c3Rkb3V0LgorICAgcHJsaW5lIHBvbGxzIHRoaXMgdG8gZGVjaWRlIHdoZXRoZXIgdG8gZGll LgorICAgU2V0dGluZyBpdCB0byBub256ZXJvIGp1c3QgYmVmb3JlIGV4aXRpbmcgY2FuIHBy ZXZlbnQgY2xlYW5fdXBfc3Rkb3V0CisgICBmcm9tIG1pc2JlaGF2aW5nIG9uIGEgYnVnZ3kg T1Mgd2hlcmUgJ2Nsb3NlIChTVERPVVRfRklMRU5PKScgZmFpbHMKKyAgIHdpdGggRUFDQ0VT LiAgKi8KIHN0YXRpYyBpbnQgc3Rkb3V0X2Vycm5vOwogCiBzdGF0aWMgdm9pZApAQCAtMTQ5 MCw3ICsxNDk0LDEwIEBAIGdyZXBidWYgKGNoYXIgKmJlZywgY2hhciBjb25zdCAqbGltKQog ICAgICAgICAgIGlmICghb3V0bGVmdCB8fCBkb25lX29uX21hdGNoKQogICAgICAgICAgICAg ewogICAgICAgICAgICAgICBpZiAoZXhpdF9vbl9tYXRjaCkKLSAgICAgICAgICAgICAgICBl eGl0IChlcnJzZWVuID8gZXhpdF9mYWlsdXJlIDogRVhJVF9TVUNDRVNTKTsKKyAgICAgICAg ICAgICAgICB7CisgICAgICAgICAgICAgICAgICBzdGRvdXRfZXJybm8gPSAtMTsKKyAgICAg ICAgICAgICAgICAgIGV4aXQgKEVYSVRfU1VDQ0VTUyk7CisgICAgICAgICAgICAgICAgfQog ICAgICAgICAgICAgICBicmVhazsKICAgICAgICAgICAgIH0KICAgICAgICAgfQpAQCAtMjY5 Niw3ICsyNzAzLDYgQEAgbWFpbiAoaW50IGFyZ2MsIGNoYXIgKiphcmd2KQogCiAgICAgICBj YXNlICdxJzoKICAgICAgICAgZXhpdF9vbl9tYXRjaCA9IHRydWU7Ci0gICAgICAgIGV4aXRf ZmFpbHVyZSA9IDA7CiAgICAgICAgIGJyZWFrOwogCiAgICAgICBjYXNlICdSJzoKZGlmZiAt LWdpdCBhL3Rlc3RzL3dyaXRlLWVycm9yLW1zZyBiL3Rlc3RzL3dyaXRlLWVycm9yLW1zZwpp bmRleCBjNjY0NGUzLi4zNTFlMzJjIDEwMDc1NQotLS0gYS90ZXN0cy93cml0ZS1lcnJvci1t c2cKKysrIGIvdGVzdHMvd3JpdGUtZXJyb3ItbXNnCkBAIC0zNyw4ICszNywxMSBAQCByZXR1 cm5zXyAyIGdyZXAgLS1saW5lLWJ1ZmZlcmVkIC12ICdeJCcgPGluID4vZGV2L2Z1bGwgMj5l cnIxIFwKIHJldHVybnNfIDIgZ3JlcCAtdiAnXiQnIDxpbiA+L2Rldi9mdWxsIDI+ZXJyMiBc CiAgICAgfHwgZnJhbWV3b3JrX2ZhaWx1cmVfCiAKKyMgZGlzay1mdWxsIGVycm9yIHdpdGgg LXEgYW5kIC0taGVscAorcmV0dXJuc18gMiBncmVwIC1xIC0taGVscCA+L2Rldi9mdWxsIDI+ ZXJyMyB8fCBmYWlsPTEKKwogIyBlbnN1cmUgZWFjaCBlcnJvciBtZXNzYWdlIGZpbGUgY29u dGFpbnMgYSAnd3JpdGUgZXJyb3InIHdpdGggYWRkaXRpb25hbCB0ZXh0Ci1mb3IgZiBpbiBl cnIxIGVycjIgOworZm9yIGYgaW4gZXJyMSBlcnIyIGVycjMgOwogZG8KICAgICBncmVwIC1F aXEgJ15bXjpdKjogd3JpdGUgZXJyb3I6IFthLXpdKycgJGYgXAogICAgICAgICB8fCB7CkBA IC00OSw3ICs1Miw5IEBAIGRvCiBkb25lCiAKICMgVGhlc2UgbWVzc2FnZXMgc2hvdWxkIGJl IGlkZW50aWNhbAotY29tcGFyZSBlcnIxIGVycjIgXAotICAgIHx8IHsgd2Fybl8gImVycjEs ZXJyMiBjb250YWluIGRpZmZlcmVudCBlcnJvciBtZXNzYWdlcyIgOyBmYWlsPTEgOyB9Citm b3IgZiBpbiBlcnIyIGVycjM7IGRvCisgIGNvbXBhcmUgZXJyMSAkZiBcCisgICAgfHwgeyB3 YXJuXyAiZXJyMSwkZiBjb250YWluIGRpZmZlcmVudCBlcnJvciBtZXNzYWdlcyIgOyBmYWls PTEgOyB9Citkb25lCiAKIEV4aXQgJGZhaWwKLS0gCjIuNDcuMAoK --------------UYIMtPfU47posZHPLu0IhYEN-- ------------=_1730527382-24331-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 1 Nov 2024 13:21:17 +0000 Received: from localhost ([127.0.0.1]:49455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6raW-0000iu-2Y for submit@debbugs.gnu.org; Fri, 01 Nov 2024 09:21:17 -0400 Received: from lists.gnu.org ([209.51.188.17]:48982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t6rQf-0000Oe-06 for submit@debbugs.gnu.org; Fri, 01 Nov 2024 09:11:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t6rQX-0003JY-Ev for bug-grep@gnu.org; Fri, 01 Nov 2024 09:10:59 -0400 Received: from nikam.ms.mff.cuni.cz ([195.113.20.16]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t6rQU-0004ke-BP for bug-grep@gnu.org; Fri, 01 Nov 2024 09:10:57 -0400 Received: from kam.mff.cuni.cz (cucumber.kam.mff.cuni.cz [IPv6:2001:718:1e03:810::a2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: jan) by nikam.ms.mff.cuni.cz (Postfix) with ESMTPSA id C6897288C69; Fri, 1 Nov 2024 14:10:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kam.mff.cuni.cz; s=gen1; t=1730466644; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=B3SDj3qBv0ug1WOU8QKFf+uMsfJWhQ4lejmhdez9Kk0=; b=VtcdMvvbM+ZBAYfxTgp0j+9U0Iu3WVxsc8AjTKQMGs3BqnvSMl0CKgiULAK79jUAhL2q5b VbpudDo8NL7omYa46ZYYvIr2ikGxyH2aS65Sx7N/JH02F/FNpjDQHc7vx2nWTdI9qXvVHu ItiH+lGHUehOCyB4J6HMZnSQoLGRKJc= Date: Fri, 1 Nov 2024 14:10:43 +0100 From: Jan =?utf-8?B?xIxlcm5vaG9yc2vDvQ==?= To: bug-grep@gnu.org Subject: Unexpected exit code of 0 when -q is set and close_stdout fails Message-ID: <20241101131043.453ohkw53kvwf6v5@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=195.113.20.16; envelope-from=jan@kam.mff.cuni.cz; helo=nikam.ms.mff.cuni.cz X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 01 Nov 2024 09:21:12 -0400 Cc: wizards@kam.mff.cuni.cz X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) 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 ------------=_1730527382-24331-1-- From unknown Mon Jun 23 02:25:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74159: Unexpected exit code of 0 when -q is set and close_stdout fails Resent-From: Martin Schulte Original-Sender: "Debbugs-submit" Resent-CC: bug-grep@gnu.org Resent-Date: Sat, 02 Nov 2024 09:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74159 X-GNU-PR-Package: grep X-GNU-PR-Keywords: To: Jan =?UTF-8?Q?=C4=8Cernohorsk=C3=BD?= Cc: wizards@kam.mff.cuni.cz, 74159@debbugs.gnu.org Received: via spool by 74159-submit@debbugs.gnu.org id=B74159.173053969915466 (code B ref 74159); Sat, 02 Nov 2024 09:29:01 +0000 Received: (at 74159) by debbugs.gnu.org; 2 Nov 2024 09:28:19 +0000 Received: from localhost ([127.0.0.1]:53121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t7AQd-00041O-B1 for submit@debbugs.gnu.org; Sat, 02 Nov 2024 05:28:19 -0400 Received: from sb.ds-gmbh.de ([91.184.37.131]:41482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t7AQb-00041I-Ey for 74159@debbugs.gnu.org; Sat, 02 Nov 2024 05:28:18 -0400 Received: from 185-232-103-115.xdsl.philuweb.net ([185.232.103.115] helo=martnix4.ds-gmbh.de) by sb.ds-gmbh.de with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1t7AQZ-00066D-NV; Sat, 02 Nov 2024 10:28:15 +0100 Date: Sat, 2 Nov 2024 10:28:12 +0100 From: Martin Schulte Message-Id: <20241102102812.acce2d34aa332d1f4d33fa23@schrader-schulte.de> In-Reply-To: <20241101131043.453ohkw53kvwf6v5@kam.mff.cuni.cz> References: <20241101131043.453ohkw53kvwf6v5@kam.mff.cuni.cz> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) Hello Jan! On Fri, 1 Nov 2024 14:10:43 +0100 you wrote: > https://grsc.cz/blog/loffice-linux-issues/, but it's mostly not relevant > for this bug). While I can't help you with grep/operating system issue I suggest replacing if echo "$checks" | grep -q "cc" ; then by if [ ${#checks} -gt 1 ] ; then It simply tests if the string inside the variable checks is longer than 1, uses less system resources and all shell features you need have already been part of POSIX 1003.1 Issue 6 from 2004. Best regards, Martin From unknown Mon Jun 23 02:25:14 2025 X-Loop: help-debbugs@gnu.org Subject: bug#74159: Unexpected exit code of 0 when -q is set and close_stdout fails Resent-From: Jan =?UTF-8?Q?=C4=8Cernohorsk=C3=BD?= Original-Sender: "Debbugs-submit" Resent-CC: bug-grep@gnu.org Resent-Date: Sun, 03 Nov 2024 22:45:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74159 X-GNU-PR-Package: grep X-GNU-PR-Keywords: To: Paul Eggert Cc: 74159-done@debbugs.gnu.org, wizards@kam.mff.cuni.cz Received: via spool by 74159-done@debbugs.gnu.org id=D74159.173067384332729 (code D ref 74159); Sun, 03 Nov 2024 22:45:03 +0000 Received: (at 74159-done) by debbugs.gnu.org; 3 Nov 2024 22:44:03 +0000 Received: from localhost ([127.0.0.1]:35406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t7jKE-0008Va-6b for submit@debbugs.gnu.org; Sun, 03 Nov 2024 17:44:03 -0500 Received: from nikam.ms.mff.cuni.cz ([195.113.20.16]:54971) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t7izH-0007pd-TW for 74159-done@debbugs.gnu.org; Sun, 03 Nov 2024 17:22:25 -0500 Received: from Think (unknown [IPv6:2a02:830a:b009:4ff1:6af7:28ff:fe19:c5c4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: jan) by nikam.ms.mff.cuni.cz (Postfix) with ESMTPSA id 3FB7A28903C; Sun, 3 Nov 2024 23:22:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kam.mff.cuni.cz; s=gen1; t=1730672531; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Fs2s3p49AEuNuvE+ldW6H7vLUz68/lJMt2l0FzhxCac=; b=IQVOEKemtdUL6QwnnZOFPhtYZI/nR0PQS4DjpvnDCB7K+BtbEu6qOqI7wYGsUkDxwRJoA5 fE9dK4LeUEpSpaLmmaYAIMMBGCH7c637niOZf3/QB/ZMHLNxBT6yA/PIRhfjDRW5DKtunE D8/IHavnoVYsWz976nEeH2cbNxj8D4s= Date: Sun, 3 Nov 2024 23:22:10 +0100 From: Jan =?UTF-8?Q?=C4=8Cernohorsk=C3=BD?= Message-ID: References: <20241101131043.453ohkw53kvwf6v5@kam.mff.cuni.cz> <1723a5e3-d1d0-46ab-9dbb-41394c91c1c3@cs.ucla.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1723a5e3-d1d0-46ab-9dbb-41394c91c1c3@cs.ucla.edu> X-Spam-Score: -2.3 (--) X-Mailman-Approved-At: Sun, 03 Nov 2024 17:43:54 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Thank you for your very swift reply and fix. >>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. The provided patch fixes the issue 👍 >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 aware. I'll try to look into it, but it seems like a much deeper rabbit hole. Thanks again, Jan