From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id D7tpOBzQRmLMSAAAWB0awg (envelope-from ) for ; Fri, 01 Apr 2022 06:12:44 -0400 Received: by simark.ca (Postfix, from userid 112) id D6C641F1F4; Fri, 1 Apr 2022 06:12:44 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C682F1E787 for ; Fri, 1 Apr 2022 06:12:43 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 449833945C3D for ; Fri, 1 Apr 2022 10:12:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 449833945C3D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1648807963; bh=yjG+VyQRTQZdiQ7C6/urWGVB3dGTYon8aIrJa591O6w=; h=To:Subject:In-Reply-To:References:Date:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=aNaYvoUy59AfRXDR2ukKgQWpqoheQYKcZaCRNXWwoJsZyKe1g/4pxhi9tffNZnC3h aZKMc7xrOWXekJDYQI/WTEMscFYu5YrvaLqrSnIqlb2I4FnffR37+5kC9KlfN/GoI/ 79wW6Zp1TlgHwIVplylIvsowGWJ1p3Pbz+I1b+js= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 924903858D28 for ; Fri, 1 Apr 2022 10:12:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 924903858D28 Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-641-H7FIoO82ODCO_Yg8o1m7Lg-1; Fri, 01 Apr 2022 06:12:22 -0400 X-MC-Unique: H7FIoO82ODCO_Yg8o1m7Lg-1 Received: by mail-wm1-f71.google.com with SMTP id h189-20020a1c21c6000000b0038c8655c40eso976962wmh.6 for ; Fri, 01 Apr 2022 03:12:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=yjG+VyQRTQZdiQ7C6/urWGVB3dGTYon8aIrJa591O6w=; b=CSTQ235eVrRKpC2j42f4VSu512aR5Eh9LEkh8Ka1J5HpJq3M+IiVZQwaUkGhAXOYKI 201nQj5Y6eaHEYuyM2odg80tn0A3RNfIN1bwn5DaZK73tXgOl0RrDWeXzdB31R6G/6HP BmVIsSEj3+7qSs3QeqGlDJOpjq6ZiGzDpKCFbFwY2eYMhPslGeaaeAevjF08XX0nI8XU lm17ypm4yQ4mSRZQOr/mmYWUufUJKjOwnkByefUKFG6ucWiNupfqLH5N5eivFiGN9DWz wk7yQFRJSmXjy7PvIbSTUcys4HpVNQ053fex51ivCME+8lTfCV6outjXD7dXY+Efao3G FyQQ== X-Gm-Message-State: AOAM531IGQVQtNnKJnfqabYk3hEjEpVg9fx0E4pjVzuXgxshSH9Lhmql tO32919TWjLGxvchKtEdJZ4CJnAXApxuoJyJWcT5sU4TTEtqV6Fqs2MKY7GauxCXGeBrxaS5GSH CBiussdqd9b9/l61MJy6KfQ== X-Received: by 2002:a05:600c:354d:b0:38c:e71a:c230 with SMTP id i13-20020a05600c354d00b0038ce71ac230mr8108143wmq.86.1648807940745; Fri, 01 Apr 2022 03:12:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxv1COs+1hQN9QHEAIYSvDlZ/l9cEEAVd+Hn5NzV9ChWF+Tnvx3o0J7nk1ZWd/qlkGdzYVwBA== X-Received: by 2002:a05:600c:354d:b0:38c:e71a:c230 with SMTP id i13-20020a05600c354d00b0038ce71ac230mr8108112wmq.86.1648807940465; Fri, 01 Apr 2022 03:12:20 -0700 (PDT) Received: from localhost (host86-169-131-113.range86-169.btcentralplus.com. [86.169.131.113]) by smtp.gmail.com with ESMTPSA id az19-20020a05600c601300b0038cadf3aa69sm14112524wmb.36.2022.04.01.03.12.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Apr 2022 03:12:19 -0700 (PDT) To: Eli Zaretskii , Pedro Alves Subject: Re: GDB 12.0.90 available for testing In-Reply-To: <83ee2i72vl.fsf@gnu.org> References: <20220320055815.2A90FA4D6C@takamaka.home> <83sfr4a93r.fsf@gnu.org> <83pmm8a7gn.fsf@gnu.org> <83o81sa6nu.fsf@gnu.org> <83ilrzap07.fsf@gnu.org> <83mth67i8m.fsf@gnu.org> <72ad3448-0ff0-f36c-d1f3-cc194c0503b8@palves.net> <83ee2i72vl.fsf@gnu.org> Date: Fri, 01 Apr 2022 11:12:18 +0100 Message-ID: <87sfqx864d.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Andrew Burgess via Gdb-patches Reply-To: Andrew Burgess Cc: brobecker@adacore.com, gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Eli Zaretskii via Gdb-patches writes: >> Date: Thu, 31 Mar 2022 10:48:18 +0100 >> Cc: gdb-patches@sourceware.org, Andrew Burgess >> From: Pedro Alves >> >> >> https://sourceware.org/bugzilla/show_bug.cgi?id=29002 >> > >> > Ping! The two issues described in this PR are IMO serious and should >> > be fixed before GDB 12.1 is released. Could someone please respond to >> > what I wrote there, and propose how to fix this without adversely >> > affecting GNU/Linux (and possibly other non-Windows platforms)? >> >> So from the bugzilla discussion, it sounds like calling setvbuf all the >> time is a bad idea. So we should call it once for a given stream early >> on, just once. That sounds reasonable to me. However, the patch you >> attached in bugzilla doesn't seem to be doing that correctly: >> >> >> 836 if (!done_once && !ISATTY (stream)) >> 837 { >> 838 setbuf (stream, NULL); >> 839 done_once = 1; >> 840 } >> 836 >> 841 >> >> because that will only do it once for all streams, and we need to do this >> once per stream. > > The above was what we did in GDB 11 and before. But what we used to do wasn't good enough. On Linux we have to turn off buffering even when 'ISATTY (stream)' is true, otherwise glibc/kernel will conspire to hide input from us. Could you give the patch below a try, please. It tries to move the setbuf calls out more so (I hope) they only get done once per stream, and before we've started reading anything from the stream. Thanks, Andrew --- diff --git a/gdb/event-top.c b/gdb/event-top.c index b628f0397cb..a55338d78a2 100644 --- a/gdb/event-top.c +++ b/gdb/event-top.c @@ -818,19 +818,6 @@ gdb_readline_no_editing_callback (gdb_client_data client_data) FILE *stream = ui->instream != nullptr ? ui->instream : ui->stdin_stream; gdb_assert (stream != nullptr); - /* Unbuffer the input stream, so that, later on, the calls to fgetc - fetch only one char at the time from the stream. The fgetc's will - get up to the first newline, but there may be more chars in the - stream after '\n'. If we buffer the input and fgetc drains the - stream, getting stuff beyond the newline as well, a select, done - afterwards will not trigger. - - This unbuffering was, at one point, not applied if the input stream - was a tty, however, the buffering can cause problems, even for a tty, - in some cases. Please ensure that any changes in this area run the MI - tests with the FORCE_SEPARATE_MI_TTY=1 flag being passed. */ - setbuf (stream, NULL); - /* We still need the while loop here, even though it would seem obvious to invoke gdb_readline_no_editing_callback at every character entered. If not using the readline library, the diff --git a/gdb/top.c b/gdb/top.c index ecd31456f03..456130856e5 100644 --- a/gdb/top.c +++ b/gdb/top.c @@ -283,6 +283,8 @@ ui::ui (FILE *instream_, FILE *outstream_, FILE *errstream_) { buffer_init (&line_buffer); + setbuf (instream_, NULL); + if (ui_list == NULL) ui_list = this; else @@ -412,6 +414,8 @@ read_command_file (FILE *stream) { struct ui *ui = current_ui; + setbuf (stream, nullptr); + scoped_restore save_instream = make_scoped_restore (&ui->instream, stream);