From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id COXYMjF9eGTVlxoAWB0awg (envelope-from ) for ; Thu, 01 Jun 2023 07:12:49 -0400 Received: by simark.ca (Postfix, from userid 112) id C2F491E11E; Thu, 1 Jun 2023 07:12:49 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=OoKPXgey; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.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 AF7261E0D4 for ; Thu, 1 Jun 2023 07:12:48 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7D1DD3857733 for ; Thu, 1 Jun 2023 11:12:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7D1DD3857733 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1685617967; bh=TztzBXmOBE0oandxa7/MbwCtLCBEGCDER2n2UQKmW7c=; h=To:Cc:Subject:In-Reply-To:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=OoKPXgeyFRctln8a/nQziBL7fYKqmNNIAgfQeBnFzT/pSPVZXRnNT4cdhPU1b/vMV k2HAjc9KUy6TRq08EWy8wWI6rnpklJVG6Yzbg6v6XMlt9wDhopNopMg/3R6FDQwHsH uB31jYPwpWLoBEYh/CuNLyhlLlYyAZzMD+1jXuQo= 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 9FB303858C41 for ; Thu, 1 Jun 2023 11:12:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9FB303858C41 Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-275-VH-O4lz9M_67BAZ_ZtTiKg-1; Thu, 01 Jun 2023 07:12:17 -0400 X-MC-Unique: VH-O4lz9M_67BAZ_ZtTiKg-1 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-30af00323b0so458668f8f.2 for ; Thu, 01 Jun 2023 04:12:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685617936; x=1688209936; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=TztzBXmOBE0oandxa7/MbwCtLCBEGCDER2n2UQKmW7c=; b=E2JO4MT5NS8ZKki0xdgxQQIJARmBl66lKWONiaBRTHPj0SHxi8tvUErEFZIKt2BVfP Ny0sWZachpwtQGOVbo64gi+hQB3zJDoIySdcyKmaexHQgP4eKsVs9GObbuuNk0vpAIwf yF/SbG0vYrQBPL8lP3YHZ+cGPMSpDsfMXUYVTrniamR+bgVxM3z0njhnGmr/EZfe4yZ/ cu1f4dyPgSG/Id9aFYYAAoBH98DykmcukC8t10LUHifrwtx8fekq5cf11TKG9o2EdBeJ CtnPAbHCAeuV+JnOSyBG3IANDoQ1345hw15kBmDLeBDxKeHTlwxj3cbdsFrAU9WacYhi 0YOg== X-Gm-Message-State: AC+VfDyCVjjf6Ew+qI2d0OHzaxh/nH9LS7Dq3slHyvLcZStVjxE2nouV hvVK8ONx7p5GTvIRn9Hx4VLgphlu6KBLRZghLelUtjp60mieUWkd2Dnd01r2/wgJU6k3/9jE7E+ uzAc1qUZWAHtOZUuvmzg3fw== X-Received: by 2002:adf:ec4c:0:b0:30a:f3f6:2721 with SMTP id w12-20020adfec4c000000b0030af3f62721mr1497124wrn.57.1685617936222; Thu, 01 Jun 2023 04:12:16 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6/+Bi3sH4qKtFn42vjP+rgHnptkO9/kqpWbNifr+gxllkXctpN/5Tep0ti06kRz6F0G4SXNQ== X-Received: by 2002:adf:ec4c:0:b0:30a:f3f6:2721 with SMTP id w12-20020adfec4c000000b0030af3f62721mr1497109wrn.57.1685617935838; Thu, 01 Jun 2023 04:12:15 -0700 (PDT) Received: from localhost (11.72.115.87.dyn.plus.net. [87.115.72.11]) by smtp.gmail.com with ESMTPSA id j12-20020a5d564c000000b0030af31c8c63sm9203311wrw.47.2023.06.01.04.12.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 Jun 2023 04:12:15 -0700 (PDT) To: Tom de Vries , gdb-patches@sourceware.org Cc: Simon Marchi Subject: Re: [PATCH] [gdb/testsuite] Fix gdb.tui/wrap-line.exp In-Reply-To: <564b8e8c-dd01-575f-f59d-d599673af54b@suse.de> References: <20230518061046.17837-1-tdevries@suse.de> <87ilcm83tt.fsf@redhat.com> <87bki253w9.fsf@redhat.com> <564b8e8c-dd01-575f-f59d-d599673af54b@suse.de> Date: Thu, 01 Jun 2023 12:12:14 +0100 Message-ID: <87ilc74esx.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 Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Tom de Vries writes: > On 5/30/23 15:45, Andrew Burgess wrote: >> Tom de Vries writes: >> >>> On 5/21/23 10:51, Andrew Burgess wrote: >>>> Tom de Vries via Gdb-patches writes: >>>> >>>>> PR testsuite/30458 reports the following FAIL: >>>>> ... >>>>> PASS: gdb.tui/wrap-line.exp: width-auto-detected: cli: wrap >>>>> ^CQuit >>>>> (gdb) WARNING: timeout in accept_gdb_output >>>>> Screen Dump (size 50 columns x 24 rows, cursor at column 6, row 3): >>>>> 0 Quit >>>>> 1 (gdb) 7890123456789012345678901234567890123456789 >>>>> 2 W^CQuit >>>>> 3 (gdb) >>>>> ... >>>>> FAIL: gdb.tui/wrap-line.exp: width-auto-detected: cli: prompt after wrap >>>>> ... >>>>> >>>>> The problem is that the regexp doesn't account for the ^C: >>>>> ... >>>>> gdb_assert { [Term::wait_for "^WQuit"] } "prompt after wrap" >>>>> ... >>>>> >>>>> Fix this by updating the regexp, and likewise in another place in the >>>>> test-case where we use ^C. >>>> >>>> Do we know why we sometimes manage to see '^C'? I guess it's a timing >>>> thing, but right now I'm at a loss for how we manage to see it. It >>>> appears that we print the wrapping line, that ends with 'W', and then >>>> wait for this to be displayed. >>>> >>>> At this point GDB should be in a stable state waiting in the >>>> event-loop. >>>> >>>> When we send \003 this should trigger an event, which should trigger >>>> async_request_quit, which should result in the 'Quit' exception being >>>> thrown, caught, and printed. >>>> >>>> I think the '^C' must be getting printed from tui_redisplay_readline >>>> maybe, but I can't see how that gets triggered with \003 in the input >>>> buffer. >>>> >>>> I only ask because if we understand why '^C' is sometimes printed then >>>> we might be able to decide if this should always be printed, or never be >>>> printed, and change GDB accordingly... >>>> >>> >>> Hi Andrew, >>> >>> yes, that's a good question. >>> >>> [ Note that it's a TUI test-case, but the FAIL we're observing is in the >>> cli part, before activating TUI, so tui_redisplay_readline has nothing >>> to do with the FAIL. ] >>> >>> I've added an assert in rl_echo_signal_char and managed to trigger it to >>> generate a core file corresponding to the FAIL condition (more details >>> in the PR). >>> >>> My guess at what happens is the following: >>> - we send a W to gdb >>> - readline handles this, and echoes it >>> - after readline echoing it, expect notices this and we send a ^C to gdb >>> - at this point readline is still in the code handling the W, and >>> handles the ^C by echoing it. >>> >>> Usually, at this point we're already back in gdb and handle the ^C >>> without echoing it. >> >> Thanks for the breakdown. I agree with your assessment. If I apply this >> patch: >> >> ## START ## >> >> diff --git a/readline/readline/readline.c b/readline/readline/readline.c >> index 0e33587f234..e5825a0a9b0 100644 >> --- a/readline/readline/readline.c >> +++ b/readline/readline/readline.c >> @@ -678,6 +678,9 @@ readline_internal_charloop (void) >> else if (rl_mark_active_p ()) >> rl_deactivate_mark (); >> >> + if (getenv ("RL_CHAR_DELAY") != NULL) >> + sleep (1); >> + >> _rl_internal_char_cleanup (); >> >> #if defined (READLINE_CALLBACKS) >> >> ## END ## >> >> Then run GDB with the RL_CHAR_DELAY environment variable set, it is now >> possible to type a character and quickly hit Ctrl-C in order to always >> see the '^C' displayed. >> >> Given the following assumptions: >> >> An application using readline in callback mode will spend most of its >> time outside of the readline code, and will therefore mostly have its >> own signal handlers installed. >> >> And, the documentation for the readline function rl_echo_signal_char >> says: >> >> If an application wishes to install its own signal handlers, but >> still have readline display characters that generate signals, >> calling this function with SIG set to 'SIGINT', 'SIGQUIT', or >> 'SIGTSTP' will display the character generating that signal. >> >> I wonder if the single call to 'rl_echo_signal_char' which can be found >> in readline/readline/signals.c should be wrapped in an `#if` such that >> this call is disabled when readline is used in callback mode? Like this >> patch: >> >> ## START ## >> >> diff --git a/readline/readline/signals.c b/readline/readline/signals.c >> index 8fedc370a1a..f10534c6872 100644 >> --- a/readline/readline/signals.c >> +++ b/readline/readline/signals.c >> @@ -271,7 +271,9 @@ _rl_handle_signal (int sig) >> sigprocmask (SIG_BLOCK, &set, &oset); >> #endif >> >> +#if !defined (READLINE_CALLBACKS) >> rl_echo_signal_char (sig); >> +#endif >> rl_cleanup_after_signal (); >> >> /* At this point, the application's signal handler, if any, is the >> >> ## END ## >> >> My reasoning would be that, when using in callback mode, it is up to the >> application's signal handler to ensure that rl_echo_signal_char is >> called if the application actually wants '^C' to be printed. If must be >> doing this or mostly '^C' would not (currently) be printed. >> >> If we hit this race condition then the application is now going to print >> a double '^C^C' string, which is also a bug. >> >> And if the applications signal handler doesn't cause rl_echo_signal_char >> to be called (like GDB) then it feels weird that in this one corner case >> we do end up calling it. >> >> In conclusion, I think I am arguing that what we have here is a readline >> bug. >> >> I'm happy to present this on the readline mailing list, but I wanted to >> discuss this with you first -- to see if I've convinced you? > > You did :) > > The bit of documentation you quoted suggests to me that it's unintended > behaviour, thanks for digging that up. Reported this issue on the readline list: https://lists.gnu.org/archive/html/bug-readline/2023-06/msg00000.html Thanks, Andrew