From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-il1-x132.google.com with SMTP id x12so103695ilg.1 for ; Fri, 09 Dec 2022 07:58:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; h=mime-version:user-agent:message-id:in-reply-to:date:references :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=OENZV2fEy0gPOGBva1mj+RXn2CqX8U2I0mrgiFBxQ1k=; b=PpJ/uL2oi60zb4w99DyUk0jjQvyYM5c1Ya1ndtoxaijk7NcR1ndhM21WbuUVrNUlRn lrpcUWHDVDRWNyBuzwN1eA+FRXXVno9myEeirZYypjgEqCioncfwVo3P3CXahFrcMHv7 pbVCmRYnYAhRYme+vxzwDZ80SYDz7e59fEqx/Jwd38YJjQAzbQw/FWXXAvMxd7cuXJ3Z AxrxhsBS7kN1TG1IERDWLIkvrgV8NbjvHblv3UjIFjMuWQYaiBxeZ6P9NUFUQWnXFnC2 nbTkZ+XxrvRZ0z4v4Y4meKBDlomYNRVAkjk4KFKnJr04vgaRUKuBmU817ug6ACykSg9v 6ZOw== 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) From: Tom Tromey 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-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: >>>>> "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