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.133.124]) by sourceware.org (Postfix) with ESMTPS id 6DFA73858D20 for ; Tue, 30 May 2023 13:45:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6DFA73858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1685454347; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=S2HNJ9/tdHHg8jI8ui7LPmw5Q775HrRZLiHuMHNgOok=; b=fetOL7l2LwvVmJSF9YXuVNkgyYGXLlB0+TrMvdQhJXfArvB62Cp7LVIayaXnEYDohTqgXr XjPlm7+kYjNewhPSwBolPv6tqH5crxydL0BePObZM24Cj+Sfy5HC3O77nQCKa3fCt1tyqJ 0RfYEb8z8O5jlqMSbUpGufGZt145faM= 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-216-UPtsCE4gNEKINvnUt7Ni0w-1; Tue, 30 May 2023 09:45:46 -0400 X-MC-Unique: UPtsCE4gNEKINvnUt7Ni0w-1 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-30ade645c59so1494519f8f.2 for ; Tue, 30 May 2023 06:45:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685454344; x=1688046344; 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=S2HNJ9/tdHHg8jI8ui7LPmw5Q775HrRZLiHuMHNgOok=; b=Cayou38vSm8g5WWJlubTqp+RzWqWKYcA12HVh3z8f+FJTA0go8Cma1m4uh4VHGV8mh PgpG7ay53+rSNtiRHX6XA7Ivq4HEip+vR+1yBlVqZRIg8coLQ75kMllIhpDnGjBj5Cq3 tHYEHvltUH19kVG0j6Ax331Dg9FUBdU8bkrov61caCaABu/CfR/a0KluUX8STQ+PFmQW yLcxejxEKmclzPQYKJbTqdZpBteClxOphYPf71HNP9dZfA1trcNhYBBI2fhz8yHEbeXN wyaCLvB1Rd5I8P8HT56dzqBVFj/iUqbBnyDvR+4BhTbXM00QyAgIkbgSce588ZmQbaVg 8vhg== X-Gm-Message-State: AC+VfDy58v1Om3dvlXPu8n1aKEcYLU+s2lGjKI4lZx41gLAQNwaf9+QG KzWdohuTP2ebNsbi64Tumn13Rfj8wCjux13RXIqpsZuikr8+Azm0Y8ErCVg7G65xHAOFxsGMNoM RJKMwkllk6X/DL3WQqQxLgTCd6LtIQg== X-Received: by 2002:a5d:58c9:0:b0:306:2d3d:a108 with SMTP id o9-20020a5d58c9000000b003062d3da108mr1616254wrf.11.1685454344652; Tue, 30 May 2023 06:45:44 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6bS982ka3qcD7BjpmNW7stDfxaa9dYZKny4jIEP/QweA1i58mD4Juk0c0GCA2zsmo0wT3Fog== X-Received: by 2002:a5d:58c9:0:b0:306:2d3d:a108 with SMTP id o9-20020a5d58c9000000b003062d3da108mr1616240wrf.11.1685454344309; Tue, 30 May 2023 06:45:44 -0700 (PDT) Received: from localhost (11.72.115.87.dyn.plus.net. [87.115.72.11]) by smtp.gmail.com with ESMTPSA id w12-20020a5d544c000000b002fed865c55esm3315761wrv.56.2023.05.30.06.45.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 May 2023 06:45:43 -0700 (PDT) From: Andrew Burgess 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: References: <20230518061046.17837-1-tdevries@suse.de> <87ilcm83tt.fsf@redhat.com> Date: Tue, 30 May 2023 14:45:42 +0100 Message-ID: <87bki253w9.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=-11.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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? Thanks, Andrew