From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id D07011F462 for ; Mon, 27 May 2019 12:02:08 +0000 (UTC) Received: from localhost ([127.0.0.1]:44385 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hVEKM-0001kv-G5 for normalperson@yhbt.net; Mon, 27 May 2019 08:02:06 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hVEFL-00060q-Pc for bug-gnulib@gnu.org; Mon, 27 May 2019 07:56:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hVEFK-0006mo-PT for bug-gnulib@gnu.org; Mon, 27 May 2019 07:56:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55812) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hVEFK-0006Z6-IX for bug-gnulib@gnu.org; Mon, 27 May 2019 07:56:54 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CD5AEC0528AC; Mon, 27 May 2019 11:56:34 +0000 (UTC) Received: from oldenburg2.str.redhat.com (dhcp-192-219.str.redhat.com [10.33.192.219]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 56EC560BEC; Mon, 27 May 2019 11:56:31 +0000 (UTC) From: Florian Weimer To: Paul Eggert Subject: Re: Why does close_stdout close stdout and stderr? References: <87muk8d295.fsf@oldenburg2.str.redhat.com> <87tve4t9mi.fsf@oldenburg2.str.redhat.com> <9a2d1a55-7dfb-8029-cb69-35824111d30b@cs.ucla.edu> <19715489.IPbOx59hZO@kdudka-nb> <87mujqj0tt.fsf@oldenburg2.str.redhat.com> <341739b0-959f-1279-dec6-53f759789ac7@cs.ucla.edu> Date: Mon, 27 May 2019 13:56:29 +0200 In-Reply-To: <341739b0-959f-1279-dec6-53f759789ac7@cs.ucla.edu> (Paul Eggert's message of "Fri, 24 May 2019 18:41:15 -0700") Message-ID: <87a7f8jeky.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 27 May 2019 11:56:35 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kamil Dudka , bug-gnulib@gnu.org, Jeff Layton , Bernhard Voelker , NeilBrown , Eric Blake Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" * Paul Eggert: > On 5/13/19 12:00 AM, Florian Weimer wrote: >>> I don't see any way around this problem in general with the closeout >>> module's current API, because when it discovers an I/O error it calls >>> _exit, and _exit also clashes with that kind of cleanup handling. >> This isn't the problem. fflush may also realistically cause SIGPIPE to >> be delivered to the process. That's all fine. > > It might be fine for some of these environments, but surely it can't > be fine for others. If I'm relying on the startup routines to issue > some sort of report for any non-signalling exit, then calls to _exit > will bypass the report. Sorry, I don't follow. If fflush (stderr) fails (or terminates the process with SIGPIPE), in the current code, then at least there isn't a memory safety violation. It's also a bit unlikely that code running later could do anything useful, given that the process or the entire system is in such a bad state. As far as I understand, the close_stdout function intends to avoid silent truncation due to an ENOSPC error. It does not call fsync, so it cannot prevent data loss as the result of a subsequent system crash, but at least it prevents silent ENOSPC data corruption with the Linux NFS implementation. >> Look at the existing workaround >> for sanitizers, and the comment in close_stream. The code is buggy > > I agree the code is a hack. But it's not buggy: it's portable to any > environment that conforms to POSIX, and that's a wide variety of > environments. As far as I know, POSIX does not say anywhere something like, =E2=80=9CNo function in this volume of POSIX.1=E2=80=902008 shall write anything to the standard error stream=E2=80=9D or =E2=80=9CNo function in this volume of PO= SIX.1=E2=80=902008 shall call the perror function=E2=80=9D. > The problem seems to be that people want to run these applications in > debugging environments that don't conform to POSIX. While I'm > sympathetic to that goal, it's not a high-priority-enough situation to > call the current code "buggy". I don't think this issue is restricted to debugging environments. Printing diagnostics to stderr is always a bit iffy, but can happen in many cases. > A better fix here would not be to pile yet another hack into this > hacky module. It would be to write a better module (we could call it > "flushout", say) that would define a function ("flushout_stream", say) > that would act like fflush but would do a better job with NFS-based > streams by playing the dup+close+fsync trick. We could then modify > coreutils etc. to use this new module instead of the old one. The hard > part is the "modify coreutils etc." part, because flushout_stream will > be less convenient to use than the current API. That's why I think we need to fix close_stdout instead. Thanks, Florian