From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sonic310-11.consmr.mail.ir2.yahoo.com (sonic310-11.consmr.mail.ir2.yahoo.com [77.238.177.32]) by sourceware.org (Postfix) with ESMTPS id F30743838CE2 for ; Fri, 9 Dec 2022 16:19:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F30743838CE2 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=yahoo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yahoo.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1670602758; bh=C9M2Bki4u1DHjUVrE9zYNuPGv+K6MVR2s42H++Il8u8=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=e7phEHoUsztA65RMwOh1pWQgLwT/LWnOEXnHS+YiXPnBGnxejXkn9JfhDsvMbE7OfCKMi9j/YbTslyvUazzZsYw2072eAAvA3ba0nyUbAOO4R7OpUxNK92jswkfYCNXmu1jg/x/WgxgtvNuPXPGyKe5wyClWGMB+Qb1aCXxCbMEB9m6Z74BHTNOLs8JfexAm8cMyWKLIffhTc2WQjNo7K2pe8/d9I8tdi8UdJfPBL0qpsV0UhyppzOjw0QG66JkAHOcPqFZ/A7FhhYJzUtQivBdaK6v/zvvH7fsUgmLrf2J0u7gWscQPqwWCzXnY0lkwn+PNmASFrZjBA1MhDVzryA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1670602758; bh=kiEvM395VxK8doa02sbZN+14Mx0IjoVioqVOl7GbUav=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=LLKNYy1OOI1Bh7hu4Ov3VciTTSOjmq8hUKeT0vREJ7HPZwM2yWfo1TVBW0PC3UOC6pUT4rmJjdQrbyBMwvIuynRBP4/V3GPlsbGe4cAE5D66DGm3gh95EMSiRYJP2CVkMomiFByiDE0k3kcfX5FJeTp5aI1NBgBMPKrX+wOxyL8O1sd7Ady2FXf+9iWPmEoNQfFq/VmjPY7fx2RBZZEaWwj5C0/nQxy8crV/6eas/jjgskIJ6haf3OB2fNEsDgdQPCJsevIO0DUkCHLQBt+R1O8RKVVIUu7keAvsbOhncXXHXxEL0bymcyELlrLhjA8QJEGCi2JhcoK9UAx2VauxSw== X-YMail-OSG: VsGmWTMVM1mPQlEQP2CyxRXDqlu3tZcke1lmGbfDKIwIKfDNnk682M_aLa2_Wqq IzeSzjjL6OOyF9h186WKeTEx7EP1KcEVQjX82EvlSheJy7euZrCIE2Pa0pxGgXJRGiOnEjcqfayw f0y3PfTuUTzYkH7yKk.iJuApGxkKs86Z2.dbwkX3rjmRJptqlr7gkDC2vMVcg69KwK1sgghNrLVk Bh58EXOSUqvSHc2eajSsUnLavkW3uP2uyPnoyf6kmDL7FyHiywWWYyExkUbJBnzqP4kCOymr1xl2 tY6ckcvZ2LxVf9On4IDyxgkMqMhmWszzAQpoHqtxQEi7ojGudhJH58E.ksBafwuTCIRUwCHCntH1 m35F5rN20gWR5av1oP_j00WunsdUlVmyih8ryaaT5_3rzAJ2G5KPHLaDblbIojuSw.XC_rtAgJPi ii7DDS5zfKZagjjqb9tBthvapWmSHDRKz52bn1UcNyXXnNCmsGfmfGzNPyzTiAkd.maXOUJw1B8P WRny8ykoCKB1DMk7T1dmPnKItHedodrk70bQ.NDnmAIlpGQ1x1CWxQhAj.zfr1ooL3N.H0IEhwd9 2Cd3pwqVDqOXdzIUMeI1tWYxN9e1N83BSLUQQ9QXbWvDVmbctMRRclqP_G1sIWNucNpzWSBl3H1M JKcyPmsMtBqkyPBZFWqKhMnieHfnzVrWQ9IiyzYnOZRuFJH_hGtd.IL3i.b3VnR4viN3ceo7e3kA qTNyEBS9WpJE_Qmpm5bwpnid157UZgDqBlrYKdNn4wLh_uxWiubMFcVEEUGDRpDq7D2qeM1xfPNm G9NX55e5gk3dlA_E9l4ouqnJ.5Z3neY1Y3.upQ77iEMpjKRkH8Fvxvr6mOhQyz0dLnJ4SRYrxKxY a.gztWn1iLs3kxUQBBY_eF7hRr.FrbCueyuyfFDKojV3569Ltl50YdvIlA0oYd15XtVGjBh4BgtW M93xoj.2juXOS.3HhcvBU_SJYmp0CEfPmjXnhdOo_7rrT2_yR2pGw_DSNVAQI9eBQX6V1xCqWVA5 6XpiGKlQxoK3wKaidkqr62FRfzF_nj2jPExhCALWGKyid_eC1ghgmkFb7ooz8kMtkKwWkjRGEMTc 1BE4YmvN25EO6OS3Z58ZNa3kz.Vg2z4XLzAwelZRVxxq3xSR6SSSQCqoxw9rqrEKQcQXTRsLEnPC JTePvaUzS1R7Td38P_V75WCqoqM2e4tk8y8KiEFBrIW68t8glYrBl2wdGNWv.PjM7WbAzRHrbM5j XkeYB3tdVeXhtP8OWeVqLp9LNXRa7PECpXhOZrYCfqs7J0bDVCL6gl664mb.uL67uHBHITSzy.PR _TrdTV7U0BHwfGGLhQy1h6kZYzbDUqgBhaTg5ceF.Gc3abchEmdpmu00mip29JcerbZh.XkhEMLA 1iIH7tDDR_2awyK80gmdNzCwDXtUVdNhJxjJbPOeE0MwrhGfy2lborBR9760AYDQ7FHjP1rVnU82 UrzLsbi8ZOS2vLek43Zyq3tNyNcuCRo1rA8aLCF_vR0m.Pm.5oO65QxOXiZ3NWPqyFLfMtvi3IxL .WpQvhtYBIe7rDGQdFFCf_E6m6dg8XCsc98l8MB5uooYkzaa2GRRyFgXxOJh..b32PpJ73oN.dCp Q59MsBUkJg9toImouhsjJNzonRMe8H2SAzSUbfUmrwql649wleKDHyY2XiZl5MAjErwOij6Y7okS 5aFONoiNnR_BfbCkAjq9N2Qq.LBh_wTaJR0p.rCNG3ZycTzkNH1hc0K7kfvK2uZz8kBJgh78QUsZ _g5cpXhsYC6cGnx1UuStR7qUL2J7VDvZgcjgueZ3OWsLXUs84rriFQIcL.c_02ggeXEeqQi5lBzV dp5bTojRQA7S1Ifxp9MrHjrlRBzQ20viI9AGflzCmzXaSIU8iZ0IPxv2g_SgQiNLNZ39BdqG.e1U 8egXkSiI1tF0oXPy1xTI42_wB1w5dzmOxAaYyBQAGbqOi4YTEnphvg1E8xTOIpKP0OB3TAs2s7b_ qlYcZGo5hSnTZrHarvR_2wfJ.6BiSPGj3ZISASf_fuKqbZ3QDrb3sGe04zsyyBNrDTArGu3AT7s1 lcaEDbgHCn8AEnnIv6mK4GTAP6W0RrX4SMQaM.UCvt28jXh_ZdEI1ZWBaZqJ2qwaugmDxuE.TvxV 5BK7sOybtfsWCc39UvgjAX7X7XeiGirgz_nCO.C79uhHbDkoeiox2_KBab0tSWsYAZmn.4FGSfIK MwEGZV7hqCA6cp2U- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ir2.yahoo.com with HTTP; Fri, 9 Dec 2022 16:19:18 +0000 Date: Fri, 9 Dec 2022 16:19:16 +0000 (UTC) From: Hannes Domani To: Tom Tromey Cc: "gdb-patches@sourceware.org" Message-ID: <1095715284.5500968.1670602756752@mail.yahoo.com> In-Reply-To: <87ilikin72.fsf@tromey.com> References: <20221205185651.2704492-1-tromey@adacore.com> <20221205185651.2704492-4-tromey@adacore.com> <102195784.4047621.1670433222150@mail.yahoo.com> <87ilikin72.fsf@tromey.com> Subject: Re: [PATCH 3/3] Fix control-c handling on Windows MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.20926 YMailNorrin X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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: Am Freitag, 9. Dezember 2022, 16:58:12 MEZ hat Tom Tromey Folgendes geschrieben: > >>>>> "Hannes" =3D=3D Hannes Domani writes: > > Hannes> I've now tested this a bit, it's a big improvement. > > Thanks for trying it.=C2=A0 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: > >=C2=A0=C2=A0 if (gdb_has_a_terminal () >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 && tinfo->ttystate !=3D NULL >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 && sharing_input_terminal (inf)) > [...] >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (!job_control) >=C2=A0=C2=A0=C2=A0=C2=A0 { >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sigint_ours =3D install_sigint_handle= r (SIG_IGN); > [...] >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gdb_tty_state =3D target_terminal_sta= te::is_inferior; > > > However later it is used: > >=C2=A0=C2=A0 if (gdb_tty_state !=3D desired_state) > [...] >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (!job_control && desired_state =3D= =3D target_terminal_state::is_ours) >=C2=A0=C2=A0=C2=A0=C2=A0 { >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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.=C2=A0 Just some simple logg= ing > 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. I should have been more clear about this. I started with 'new-console on', so sharing_input_terminal() returned false= , and that's why sigint_ours was not set. So yes, gdb::optional would probably fix this. I just wonder if this is never an issue on Linux, e.g. if you attach, of does signal() maybe ignore NULL-pointer functions? > Hannes> And for some reason one of my builds (x86_64+TUI+python) needed t= he > Hannes> #include in mingw-hdep.c, but my other (i686 basic) di= dn't. > > I didn't see this but I went ahead and added the include to my patch, > since it seems harmless. Great, thanks. > Hannes> But my basic i686 build had another problem when starting a progr= am with > Hannes> 'new-console on', because at program start it called install_sigi= nt_handler(), > Hannes> but rl_set_signals() would later override the SIGINT handler agai= n, so C-c > Hannes> didn't work work in this situation. > Hannes> With 'new-console off' this didn't happen, since install_sigint_h= andler() was > Hannes> again called later since it shared the console. > > I really don't understand the interaction between signal and > SetConsoleCtrlHandler.=C2=A0 I tried searching for some docs on this but > didn't find anything that was really enlightening. As far as I could tell, signal() calls SetConsoleCtrlHandler(), probably similar to how you handled this. > 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.=C2=A0 The interactions with > readline are pretty hard to understand.=C2=A0 I guess the question is whe= re > should install_sigint_handler be called where it is not called -- that > is, to reset the signals from readline.=C2=A0 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. Again, I wasn't clear enough here. The difference is not because of i686 and x86_64, but that the x86_64 build has TUI+python enabled, but my i686 build has not. Some TUI startup code would later call install_sigint_handler() again, overriding the SIGINT handler again, and everything is fine. Sorry that I wasn't clear enough before. Hannes