From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id rDruHipbk2OPJyMAWB0awg (envelope-from ) for ; Fri, 09 Dec 2022 10:58:34 -0500 Received: by simark.ca (Postfix, from userid 112) id 6F6BD1E124; Fri, 9 Dec 2022 10:58:34 -0500 (EST) 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=LYZfYQeO; 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=-8.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 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 0C12F1E0D3 for ; Fri, 9 Dec 2022 10:58:34 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D63613837590 for ; Fri, 9 Dec 2022 15:58:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D63613837590 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1670601512; bh=OENZV2fEy0gPOGBva1mj+RXn2CqX8U2I0mrgiFBxQ1k=; h=To:Cc:Subject:References:Date:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=LYZfYQeOSJsUPzVZS5Mevr0Ok3NAACzQrymoJio8+BboriGd0+u4R3vBroJs7n9Ug yQj0dwgx5O1UoEwmfjXqOVkNgjUj+wIfPKqnzbASAwFa/6VQFrdEaxrXM7YYoFCYH4 n8WluSRTz9o4rksrVS4wcPEwsC62EbuHCjgxdhMI= Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) by sourceware.org (Postfix) with ESMTPS id 1ED833838F3D for ; Fri, 9 Dec 2022 15:58:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1ED833838F3D Received: by mail-il1-x132.google.com with SMTP id x12so103695ilg.1 for ; Fri, 09 Dec 2022 07:58:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OENZV2fEy0gPOGBva1mj+RXn2CqX8U2I0mrgiFBxQ1k=; b=NmmGNEAZ8dOCrOPYd1YruLN4egawK8mv8ZOVblkWE1Ismwe6UL0ryQBB9Bs4b5ymoH gg3hM1aYDofljc/WnG9O443WcuZT8tkhFO3f8xpbsgY9Jbt+TEqcAwS5p0y36PokEtRy iW/+Ll+cEG1lmrujb+IV9nqft36l7MjLtYlTel5ntobUHxvLGww+li7gqtjKSvZQxMnK wd7ngLD6n9rjf8ZFN8zhav+LFLEXFC9AhoXkuYomhQu5PPTHO3uR4JPxnM3TSuVMGB32 zSl4eLMT8cm+r38ITFRBI7ItWER/KjlpvcUz3Vxogm/R4B7NAzj8SeEqWlpn/xFwC5fB n8gQ== X-Gm-Message-State: ANoB5plqfsvlB6YUoIM+RZyUies8F1BkHzBJnPfWWNuntaleEiR0IG/9 gAWx9//0Si/mjSHiZAGSvc6kDw== X-Google-Smtp-Source: AA0mqf7foVfMh7agWe2bbdlHGwa0URS3s50uiQ+KQq6rOapI9On7YoK2Z6emvIJffu5CKAWFJ0hvTw== X-Received: by 2002:a05:6e02:486:b0:303:8ffb:9345 with SMTP id b6-20020a056e02048600b003038ffb9345mr2732464ils.17.1670601491187; Fri, 09 Dec 2022 07:58:11 -0800 (PST) Received: from murgatroyd (97-122-76-186.hlrn.qwest.net. [97.122.76.186]) by smtp.gmail.com with ESMTPSA id r1-20020a92c501000000b00300e8df48f9sm545314ilg.9.2022.12.09.07.58.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 09 Dec 2022 07:58:10 -0800 (PST) To: Hannes Domani Cc: "gdb-patches@sourceware.org" , Tom Tromey Subject: Re: [PATCH 3/3] Fix control-c handling on Windows References: <20221205185651.2704492-1-tromey@adacore.com> <20221205185651.2704492-4-tromey@adacore.com> <102195784.4047621.1670433222150@mail.yahoo.com> X-Attribution: Tom Date: Fri, 09 Dec 2022 08:58:09 -0700 In-Reply-To: <102195784.4047621.1670433222150@mail.yahoo.com> (Hannes Domani's message of "Wed, 7 Dec 2022 17:13:42 +0000 (UTC)") Message-ID: <87ilikin72.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 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: Tom Tromey via Gdb-patches Reply-To: Tom Tromey Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" >>>>> "Hannes" == Hannes Domani writes: Hannes> I've now tested this a bit, it's a big improvement. Thanks for trying it. I appreciate that. Hannes> When I first started a program with 'new-console on', then the Hannes> sigint_ours variable would not be initialized, and I would later get Hannes> a crash on C-c. I looked at this and my feeling is that this is a latent bug. I think what's going on is that sigint_ours is set under different conditions than it is used. That is, it is set like: if (gdb_has_a_terminal () && tinfo->ttystate != NULL && sharing_input_terminal (inf)) [...] if (!job_control) { sigint_ours = install_sigint_handler (SIG_IGN); [...] gdb_tty_state = target_terminal_state::is_inferior; However later it is used: if (gdb_tty_state != desired_state) [...] if (!job_control && desired_state == target_terminal_state::is_ours) { install_sigint_handler (sigint_ours); It's maybe hard to reason about but it seems to me that there's some possibility for the value to be used even though it hasn't been set, and I suspect that is what you are seeing. It might be useful if you could confirm this. Just some simple logging at these two points would be sufficient. If that's the issue then I can write a patch to change sigint_ours to be a gdb::optional and check it that way. Hannes> And for some reason one of my builds (x86_64+TUI+python) needed the Hannes> #include in mingw-hdep.c, but my other (i686 basic) didn't. I didn't see this but I went ahead and added the include to my patch, since it seems harmless. Hannes> But my basic i686 build had another problem when starting a program with Hannes> 'new-console on', because at program start it called install_sigint_handler(), Hannes> but rl_set_signals() would later override the SIGINT handler again, so C-c Hannes> didn't work work in this situation. Hannes> With 'new-console off' this didn't happen, since install_sigint_handler() was Hannes> again called later since it shared the console. I really don't understand the interaction between signal and SetConsoleCtrlHandler. I tried searching for some docs on this but didn't find anything that was really enlightening. Also it's somewhat surprising that the x86 and x86-64 builds would be different in this regard. Anyway ... I'm not sure what to do here yet. The interactions with readline are pretty hard to understand. I guess the question is where should install_sigint_handler be called where it is not called -- that is, to reset the signals from readline. Alternatively, where is it called on x86-64 but not on x86? I did try 'new-console on' with my (x86-64) build, and that worked fine. I can try an x86 build and see if that works any better. Tom