From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) by sourceware.org (Postfix) with ESMTPS id 7BBAF3858D3C for ; Mon, 14 Feb 2022 18:37:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7BBAF3858D3C Received: by mail-ot1-x330.google.com with SMTP id j38-20020a9d1926000000b0059fa6de6c71so12171490ota.10 for ; Mon, 14 Feb 2022 10:37:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=hh55fUpzVzJI02OWmdDSYauNxdo5Rh8dTxwgmMlGncQ=; b=HX0aNeom0fnVD6FXN+zgf1G5m0TdAPGs38IouOfj46HCq8Ng4FOEcvXMDBow0e9WMn Qr3zehkQg8IRaqZd1VAICfznWtimKT4qrw2s6OGpgxIs64s81UoUIN3mtvn2SPF+VTBh 66qQeBqaysNOxxPRcjqCUrzfcWZZDdC+jFHy/+JHdKhQFZly2fw2Goo82YuQ2jgleQXS /mXWvWUIuSMcTG/mAnhmoYwkEckTAOmdO23g9oz9XLaM/y58C/zYIMPNVGvFjYq3YhvI MjRkl8Fn+E60/wPVR0D3BWUy1jcRcjGqmyEgzf+HckWXRd318TtQt6+u7C2qTfS5mBMB rEUg== X-Gm-Message-State: AOAM532404DN99x2IeLjKYSr03dkwutb7DBxA9sNtqUjhyzetG2s5IH2 D42FBkfRFZC+yvlHwyEbuUUeKA== X-Google-Smtp-Source: ABdhPJwl0xc1q9aQScis1MDPPLz3izeHIUJX3jca6B2sQGMAN312dUtBairyWPJb3DCIW14/qDLWuw== X-Received: by 2002:a05:6830:10d6:: with SMTP id z22mr103889oto.106.1644863865836; Mon, 14 Feb 2022 10:37:45 -0800 (PST) Received: from ?IPV6:2804:431:c7cb:6747:70ce:2039:9f74:f513? ([2804:431:c7cb:6747:70ce:2039:9f74:f513]) by smtp.gmail.com with ESMTPSA id bg34sm13428104oob.14.2022.02.14.10.37.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Feb 2022 10:37:45 -0800 (PST) Message-ID: Date: Mon, 14 Feb 2022 15:37:43 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: [PATCH] libio: Ensure output buffer for wchars (bug 28828) Content-Language: en-US To: =?UTF-8?Q?Jos=c3=a9_Bollo?= Cc: libc-alpha@sourceware.org References: <391bad58-2186-93db-c1bc-663e7fbe6345@linaro.org> <20220214191018.64bc4b69@d-jobol.iot.bzh> From: Adhemerval Zanella In-Reply-To: <20220214191018.64bc4b69@d-jobol.iot.bzh> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.9 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 18:37:48 -0000 On 14/02/2022 15:10, José Bollo wrote: > On Mon, 14 Feb 2022 11:15:46 -0300 > Adhemerval Zanella wrote: > >> On 13/02/2022 16:52, jobol@nonadev.net wrote: >>> When fileops.c checks for nullity of the write pointer, >>> in order to ensure its allocation, before that patch, >>> wfileops didn't. This was leading to crashes on some cases, >>> as described by bug 28828. >>> >>> The minimal sequence to produce the crash was: >>> >>>     #include >>>     #include >>>     int main(int ac, char **av) >>>     { >>>             setvbuf(stdout, NULL, _IOLBF, 0); >>>             fgetwc(stdin); >>>             fputwc(10, stdout); /*CRASH HERE!*/ >>>             return 0; >>>     } >>> >>> The line "fgetwc(stdin);" is necessary. It introduces the >>> bug by setting the flag _IO_CURRENTLY_PUTTING of stdout >>> indirectly (file wfileops.c, function _IO_wfile_underflow, line >>> 213). >>> >>> Signed-off-by: Jose Bollo >> >> Patch looks ok, but git-pw fails to apply it: >> >> $ git-pw patch apply 51088 >> Applying: libio: Ensure output buffer for wchars (bug 28828) >> error: patch failed: libio/wfileops.c:412 >> error: libio/wfileops.c: patch does not apply >> error: Did you hand edit your patch? > > I copied the ouput of [git format-patch], following as much as possible > https://sourceware.org/glibc/wiki/Contribution%20checklist but didn't > used [git send-email]. I don't have the command [git pw] that you are > using. I can see that [git apply] produce the same issue but [git am] > perfectly works. The main problem is even without using git-pw it does fail (the buildbot has throw an issue as well). From the weekly call it seems that your email client (or the way you have sent the patch) replaces the already existing tab with whitesapce. > >> Could you resend it? > > I can try but maybe you have a hint avoiding me to do the same... > >> Also, could you also provide a regression testcase for this fix? > > Why not. Where? a libio/bug-XXX.c ? I think it preferable to follow current trend, so libio/tst-bz28828.c. > >>> --- >>>  libio/wfileops.c | 5 +++-- >>>  1 file changed, 3 insertions(+), 2 deletions(-) >>> >>> diff --git a/libio/wfileops.c b/libio/wfileops.c >>> index fb9d45b677..aa94a22983 100644 >>> --- a/libio/wfileops.c >>> +++ b/libio/wfileops.c >>> @@ -412,10 +412,11 @@ _IO_wfile_overflow (FILE *f, wint_t wch) >>>        return WEOF; >>>      } >>>    /* If currently reading or no buffer allocated. */ >>> -  if ((f->_flags & _IO_CURRENTLY_PUTTING) == 0) >>> +  if ((f->_flags & _IO_CURRENTLY_PUTTING) == 0 >>> +      || f->_wide_data->_IO_write_base == NULL) >>>      { >>>        /* Allocate a buffer if needed. */ >>> -      if (f->_wide_data->_IO_write_base == 0) >>> +      if (f->_wide_data->_IO_write_base == NULL) >>>      { >>>        _IO_wdoallocbuf (f); >>>        _IO_free_wbackup_area (f); >