From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24270 invoked by alias); 30 Jul 2014 12:38:09 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 24231 invoked by uid 89); 30 Jul 2014 12:38:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 30 Jul 2014 12:38:02 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6UCbxwK028428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 30 Jul 2014 08:37:59 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6UCbvZk019515; Wed, 30 Jul 2014 08:37:58 -0400 Message-ID: <53D8E725.8080902@redhat.com> Date: Wed, 30 Jul 2014 12:46:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Doug Evans CC: gdb-patches Subject: Re: [pushed+7.8] Re: [PATCH] Fix "attach" command vs user input race [Re: Regression for attach from stdin [Re: [pushed] Re: [PATCH v6 0/2] enable target-async by default]] References: <1400878753-24688-1-git-send-email-palves@redhat.com> <538739A2.2050105@redhat.com> <20140701162830.GA25877@host2.jankratochvil.net> <1404291574.3766.35.camel@bordewijk.wildebeest.org> <53B3CDCC.9050502@redhat.com> <53B57911.10304@redhat.com> <53B6B0B8.2050702@redhat.com> <21434.52532.737427.778289@ruffy.mtv.corp.google.com> <53BC0D0B.7040001@redhat.com> <21437.28600.751354.629884@ruffy.mtv.corp.google.com> <53BD7749.5000800@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-07/txt/msg00785.txt.bz2 On 07/29/2014 11:03 PM, Doug Evans wrote: > A related issue (or the same one if one prefers): > > post_create_inferior does this: > > /* Be sure we own the terminal in case write operations are performed. */ > target_terminal_ours (); Yeah. As I mentioned before, when I wrote a test that sends a ctrl-c right after "attach", which triggered the issue mentioned in the new comment, - installs a SIGINT handler that forwards SIGINT to the inferior. Otherwise a Ctrl-C pressed just while waiting for the initial stop would end up as a spurious Quit. it tripped on a set of other races. This call was one of them. We should actually be calling target_terminal_ours_for_output, not target_terminal_ours, so that stdin/ctrl-c is still redirected to the inferior. As is, IIRC, if a ctrl-c arrives after than target_terminal_ours and before the next target_terminal_inferior, we end up in the prompt, with a Quit, but with the target still running. I gave up fixing those at the time, as they're orthogonal to sync/async. > > but post_create_inferior is called *after* target_post_attach > in attach_command_post_wait: > > /* Take any necessary post-attaching actions for this platform. */ > target_post_attach (ptid_get_pid (inferior_ptid)); > > post_create_inferior (¤t_target, from_tty); > > What if target_post_attach does some writes? Something should call target_terminal_ours_for_output before. > Seems like it can, e.g., some of the ptrace checking stuff may print a warning. > Plus attach_command_post_wait calls some other stuff before > post_create_inferior that could cause some writes to the terminal. > > Question: Is there a specific terminal state that needs to be in > effect when attach_command_post_wait returns? > Or can we just call target_terminal_ours at its start? I think we can. > [and leave it to other code to switch back to target_terminal_inferior > as needed - e.g. proceed calls resume which will call > target_terminal_inferior] Even with that, it'll still be possible to have a ctrl-c pressed after to_attach is called, and before target_terminal_inferior is called (and therefore set_sigint_trap is called, which sets up ctrl-c forwarding). When I last looked at this, it seemed to be that ideally, we should only have a single SIGINT handler, which just records that a ctrl-c was pressed, and then the event loop decides whether a ctrl-c is a Quit or whether it should be forwarded to the inferior, depending on whether the target is running on the foreground, or not. -- Thanks, Pedro Alves