From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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) From: Andrew Burgess To: Eli Zaretskii , Pedro Alves Cc: gdb-patches@sourceware.org, brobecker@adacore.com 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-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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: 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: , X-List-Received-Date: Fri, 01 Apr 2022 10:12:25 -0000 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);