From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2097.outbound.protection.outlook.com [40.107.244.97]) by sourceware.org (Postfix) with ESMTPS id D8FFA385483F for ; Fri, 30 Sep 2022 21:08:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D8FFA385483F Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=microsoft.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=microsoft.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YAddsgM9Zo7Jrq6zylBuAmtQeW57gs1szNmad9C1+TmOqDGymzF58W/7KHjqfqi29gyPhBiVuqqNdr8jlSabTk44fYdXhVABCVQUtfz3nmAMVonx9BGJyC/LBw7PLHUVfdzDuX2JccAzAass7NmZrQHzWG5wLu8aj52tOE4c18O5R3djPGzOe8Im/KlfMCfFPz8sbdGbRPqP1WqvV8L+oGevahqp0AtoSp5/Bof9bnlBzWr/vUM7grZ6WegUxIe3UF7Jv4/NzvXJ/KXkrBxiyLzjNGKTk/GrjymS9Ifb1V13a5z1oemnKFltIKelWxQA1yTAqBJV7s8nfFmKblVLBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=UB0GykOt6CjmFMzLDvx0YnFQQs7TVopEi9MfAq34FZE=; b=TvX85LxqTZbK/BTQ/vDH1FDnPxJfoAg76gOrOqZy1hwBKs6YkNVsyjqaEsM8aA1rReMhLuaeGlSC+f4nG+G55/ukTCw1RfjePX60CGuV0HkWv+awLuszvfcETUdtZrIJCxRUrik75QtOwelYiewGmGNhTc8j/lISkRlJW6g+sGE1nfbJ+3j2KQhFjPJ6agcQHSKLryEVOHpVp5yjp+NhrDdbc7HovpPBrtcH6rh2JFGp8x0o9eiBGT+8fzVET3mKi1+Rjvkk9wL1pyf308BuYH90vrswlUk+BO7SN5fkjDIKepAt4vSFs0GFoe1HcNawLusdWIxqmJJlHzUfEFd8BQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UB0GykOt6CjmFMzLDvx0YnFQQs7TVopEi9MfAq34FZE=; b=iTQ0e4fb8uhKkmiBjnXp/YQji/WNhrxSe7/ocxQaU1EhJZXs81d5Jdj37sUOPWiVMyZ7dCpj2kW92R0gTw5K36PCUphZsxGMSTkPt4w+qoJi7mRXBLWsmcnS4kMGXLs9+AmrcqwsSvxJl/aqA8Ux+M4ucmUl8+q8ikuE0HIrb/I= Received: from MN2PR21MB1439.namprd21.prod.outlook.com (2603:10b6:208:20a::15) by DS7PR21MB3222.namprd21.prod.outlook.com (2603:10b6:8:7a::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5709.3; Fri, 30 Sep 2022 21:08:47 +0000 Received: from MN2PR21MB1439.namprd21.prod.outlook.com ([fe80::b272:3127:8ae:4a12]) by MN2PR21MB1439.namprd21.prod.outlook.com ([fe80::b272:3127:8ae:4a12%5]) with mapi id 15.20.5709.001; Fri, 30 Sep 2022 21:08:47 +0000 From: Bill Messmer To: Simon Marchi , "gdb@sourceware.org" Subject: RE: [EXTERNAL] Re: Issues With Thread Events In User Mode GDBServer Thread-Topic: [EXTERNAL] Re: Issues With Thread Events In User Mode GDBServer Thread-Index: AdjEhp9G/nFU1LmjTkSOuj12IeJY0wBiXbQAADGsXyAAPM86AANOSdHA Date: Fri, 30 Sep 2022 21:08:47 +0000 Message-ID: References: <054cd411-885d-443e-d357-1c517315dbcb@simark.ca> In-Reply-To: <054cd411-885d-443e-d357-1c517315dbcb@simark.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=a1976a94-b438-4c3c-8e55-79c3b9b50381;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2022-09-30T19:31:00Z;MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MN2PR21MB1439:EE_|DS7PR21MB3222:EE_ x-ms-office365-filtering-correlation-id: 99026227-4005-44fe-aec4-08daa327f76d x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: b078P8IKXVU7q3Y8eFa1VbUmim7Z93Nx4C1EIf7YHNn3QIT15lQRf0fWZs21Jtewc1osN79UMq918Ee1SHK2K0uZSYbxNEQEpBUQZQLc+R/9ZE4zS7yLclzlGp8ZUDG80YrdsENtHo2dn6Z3zVFujQRXYAcPexKTpAlGzyppLBaZIDWMYoPv42kezaK43cqflrY187cjBj193x3b0A4L3NNzeZdZE3QUrblv/eRy5Y8apqfk9jnu/TBjGu3Q95Ka5UwxR4IIyLqIuWnp1fx8+gf5omuhRVpWg9Xw7SutAZrcnelTl2YRxf0eRtkpvnU8tKbMMRea1WLLXF9xjjwrltFUqLME/z2Ff+H2zdZvkmvR4M82lTafLGhgHAUGxlelCTLBjtaMrRvbbHhS+URpalLY9YNd5eKEw5eLVELNdeKo9vAbeD6g8iHD+G7u+4XaUrxzFKsA7ZrOURxIpCCYJZfF1B/8+tVrYskw4VI+i2gBvpbe3k7NRhM65SfcprWxQCEbG9Fjcl4uyFSwNQI2Pxon7XLiA6EO7i8cvK+H//boQE92gbbEkFS+SdemrZ9P3n8ucqQOWcDfLoibWHvbgCbTCn5bjaUlg/nFHBBfjbbbW5IWkSX2MTYeAKK0xLdCMvKGZ4e9oXeL92IwZCYEyzkZhgDtp28Ma5MtJsBl9ZAJTSmBpj9e09fIKB/+KmWlwa3kbU17Z0No/zpwb6LOuZCTH0XBHIiuPg0Ojj3z4gHh0COtzlCv4OgismkYRyl/yH1czCHVF04YfBK8wHRbS3Z04SIAxt9DiVU2WwmuWkdjJCbjj5Zwa0xi2RYFq7Num3UMa5dt2IwGdEUWBiDtrQ== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MN2PR21MB1439.namprd21.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(376002)(396003)(346002)(136003)(366004)(39860400002)(451199015)(9686003)(186003)(2906002)(4001150100001)(6506007)(7696005)(41300700001)(5660300002)(53546011)(52536014)(8936002)(66476007)(66446008)(64756008)(8676002)(66556008)(66946007)(76116006)(38100700002)(122000001)(33656002)(38070700005)(82960400001)(82950400001)(83380400001)(8990500004)(55016003)(86362001)(478600001)(110136005)(966005)(10290500003)(316002)(71200400001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?/ObzUV5jPsilYObyeiXRJlKKIzkNucYuychry/rxPtI52KSHa3IxWovMVsbC?= =?us-ascii?Q?OQx5B4UW46GzbOI0PZr4GXaBDMF8hSSQW/LSVE+IYshksp9eS+d8T0sJYLvj?= =?us-ascii?Q?HwYbO0O6vBTIkkWYgnqjHr/FTPUE1x/25pYghVLDlXdAzi5Pc4+JedHRQ5d5?= =?us-ascii?Q?H5aOXK1bvnx18eWJ0ZQ4EB8fBNnq3hatQ61nCREmvtR1Entb8nHqIHOSkHo8?= =?us-ascii?Q?eoeI6UDJ3E8HA9PGp6NJmfiCCRnkikGOcvGYOgNE8bvh8rOrZbL3Digl04u1?= =?us-ascii?Q?BZSAyGUW7g9WKwaL31FLW/3Rm+W/MsGiT9Rjv58e10T7hQR7cuL6bRnJ0Vux?= =?us-ascii?Q?6wQD7NNpbSOzerQ5d5wghGQ8CgvLVPQiLGRFt4cws6JOaSegh2lAUU6dxBcZ?= =?us-ascii?Q?0fYa5QVKpi+pUwWod9xdhnniV6mBW5LuvbBf1CMlxluXfWYXpz5RWREAFxbj?= =?us-ascii?Q?pSbr6pt9AjLlfvZ2vc02yYSKQxu/71KjdrPmRVNsAZbwPHJceiCbBJvQU9xy?= =?us-ascii?Q?ZbwxaSU35K4aMQIDLjGOsO4jvgZeK7HWQ5Frnx2K7drHnuvCFrNSFbiYndam?= =?us-ascii?Q?8U/2RNHNUhUeWg6F6SGvRT95VhsQfHWa0AEWvd5KJ1fTutjE4ACr6r0cP5aD?= =?us-ascii?Q?q0OYUnEdQeXHik2Z6XtUKVK4rAOQKU/IfoXuAJz5vS/D9gLEkp5SJPEwstVu?= =?us-ascii?Q?RgOFFG8cjKdijzLbmNmbRwrqpXblJRiWxFlkEOrTmVII585Jw+O4r/yb8/eJ?= =?us-ascii?Q?xyo1sCnoQyys0wSr4XdDRrsjGl0ONkqWYqNAzxANqkKfCNDqV0WUYALUX5m+?= =?us-ascii?Q?81DJJCwnqUxVO9L9G/PhEzLRGGA4d2DgTSPaJLr/KRDgK8u7XZWnDVUMrrHi?= =?us-ascii?Q?CQe/8C7b09dq2URMBt1FWLdwyUX6+TmrFSmwVtKLyjW59mxcHsjlQh6aE25e?= =?us-ascii?Q?gai7t93srv9yLyKAQntUAHx9jdC+H3FI8IAaJLUMFZW2JTtByDyAmWJR3d0A?= =?us-ascii?Q?rPTReP1Aj0IMNtaMoeurrAKcbYV5eWT57s3WJkc0ZbAgKDaSU9yZX1VTSBD6?= =?us-ascii?Q?E8ydwEpRpJPPZOMf90agZvq37/laRlqGXFIn73KwEoJpuJEd1MV9s0Ie/moG?= =?us-ascii?Q?KPT2RGvTVc94hk8egzEye6z88/9QTurRHsfNOJILdODPoffre8tNzPa0g7GF?= =?us-ascii?Q?1WmWWZBA6vC+BUcpKTsw5uh2ck0g83PTjTozBAs6CIN+HMQIOS1eqH97KubS?= =?us-ascii?Q?NKWauwGC+fwP9dPQyIbThQykaBTg2oPFb5cZb/DY8SWAItQiVrHDJGApxzCV?= =?us-ascii?Q?AhXj1auEUpBqTXHqgP71TF0mRDlpo7WVQFoR3UZy5LYPXimnXyOT9cSgn44/?= =?us-ascii?Q?aK8+cA6zJWfTDg/+IApTAXjVPtorcFnVoMCxLxsGf557wQ25NnmnivX+yDUJ?= =?us-ascii?Q?FpSm3ePiad8De6F9+4z3sAt5edzPdlBSIuRNp8A8UACrCaaekHaF7d5+Wx/x?= =?us-ascii?Q?kTu8ouRZ1+lzj0Q3RPkn7pq/jVG3bp5QiHY0Y+8ezCg5xEpSGLp8LaALiXTx?= =?us-ascii?Q?+PaJgemnr+5ZsJoXqyVxEcL0kQ1ORzyx1DJ1JnlRg5XV/hXRpczoauMJJp37?= =?us-ascii?Q?arcLw70MdPngPMgcEh2isdqSCx8QQCbqh7aSMxpgLlky?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR21MB1439.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 99026227-4005-44fe-aec4-08daa327f76d X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2022 21:08:47.6402 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: scgagYXiX9sVBSlWuTuIU7jBIvgF0obBOA6WMkpV4B37zAUErbr7PJUvRYeCropiY8l2xGa14t93c8WftqxKzA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR21MB3222 X-Spam-Status: No, score=-9.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,TXREP,WEIRD_PORT 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: Simon, Apologies for the delay in response. I finally had a bit of time to debug = through gdbserver while trying to get all of this working on my side... linux_process_target::wait_1 does *NOT* call stop_all_lwps at all (even in = full stop mode) if the event is a termination event. The relevant block is= the large if (WIFEXITED (w) || WIFSIGNALED (w)) { ... if (ourstatus->kind () =3D=3D TARGET_WAITKIND_EXITED) return filter_exit_event (event_child, ourstatus); return ptid_of (current_thread); } I went and tweaked this to: if (WIFEXITED (w) || WIFSIGNALED (w)) { ... if (ourstatus->kind () =3D=3D TARGET_WAITKIND_EXITED) result =3D filter_exit_event (event_child, ourstatus); result =3D ptid_of (current_thread); if (!non_stop) { stop_all_lwps(0, NULL); } return result; } With the tests I have, things appear to largely work as a I'd expect after = making these changes. Again -- I have little familiarity with GDBServer, s= o I don't know if I'm missing something here. If this seems reasonably correct to you -- I'm happy to submit a patch. Sincerely, Bill Messmer wmessmer@microsoft.com -----Original Message----- From: Simon Marchi =20 Sent: Tuesday, September 13, 2022 4:39 PM To: Bill Messmer ; gdb@sourceware.org Subject: Re: [EXTERNAL] Re: Issues With Thread Events In User Mode GDBServe= r [You don't often get email from simark@simark.ca. Learn why this is importa= nt at https://aka.ms/LearnAboutSenderIdentification ] > The GDBServer then segfaults when the first thread exits. GDB itself sho= ws that the gdbserver faulted at: > > Program received signal SIGSEGV, Segmentation fault. > resume (actions=3Dactions@entry=3D0x55e85605f590, num_actions=3Dnum_a= ctions@entry=3D1) at /build/gdb-wIRHdd/gdb-12.0.90/gdbserver/server.cc:2966 > 2966 /build/gdb-wIRHdd/gdb-12.0.90/gdbserver/server.cc: No such fi= le or directory. > (gdb) bt > #0 resume (actions=3Dactions@entry=3D0x55e85605f590, num_actions=3Dn= um_actions@entry=3D1) > at /build/gdb-wIRHdd/gdb-12.0.90/gdbserver/server.cc:2966 > #1 0x000055e854c61020 in handle_v_cont (own_buf=3D0x55e85604aed0 "vC= ont;c") > at /build/gdb-wIRHdd/gdb-12.0.90/gdbserver/server.cc:2910 > #2 handle_v_requests (own_buf=3D0x55e85604aed0 "vCont;c", packet_len= =3D, > new_packet_len=3D) at /build/gdb-wIRHdd/gdb-12.0.9= 0/gdbserver/server.cc:3177 > #3 0x000055e854c6299e in process_serial_event () > at /build/gdb-wIRHdd/gdb-12.0.90/gdbserver/server.cc:4523 > #4 handle_serial_event (err=3D, client_data=3D) > at /build/gdb-wIRHdd/gdb-12.0.90/gdbserver/server.cc:4555 > #5 0x000055e854c994b6 in gdb_wait_for_event (block=3Dblock@entry=3D1= ) > at /build/gdb-wIRHdd/gdb-12.0.90/gdbsupport/event-loop.cc:700 > #6 0x000055e854c9994b in gdb_wait_for_event (block=3D1) > at /build/gdb-wIRHdd/gdb-12.0.90/gdbsupport/event-loop.cc:596 > #7 gdb_do_one_event () at /build/gdb-wIRHdd/gdb-12.0.90/gdbsupport/e= vent-loop.cc:237 > #8 0x000055e854c50872 in start_event_loop () > at /build/gdb-wIRHdd/gdb-12.0.90/gdbserver/server.cc:3553 > #9 captured_main (argv=3D, argc=3D) > at /build/gdb-wIRHdd/gdb-12.0.90/gdbserver/server.cc:4033 > #10 main (argc=3D, argv=3D) > at /build/gdb-wIRHdd/gdb-12.0.90/gdbserver/server.cc:4119 Thanks for the detailed report. A bit of background: the only time GDB ever requests thread events from GDB= server is in non-stop mode, when it wants to stop all threads. It is the c= ase described in the QThreadEvent documentation: For example, this is used in non-stop mode when GDB stops a set of threads and synchronously waits for the their corresponding stop replies. Without exit events, if one of the threads exits, GDB would hang forever not knowing that it should no longer expect a stop for that same thread. By using QThreadEvents in all-stop mode, you likely trigger some different = code path (not a reason for GDBserver to crash, of course). I think I was able to reproduce the crash using GDB, with this simple patch= that enables thread events all the time, just like you do: diff --git a/gdb/remote.c b/gdb/remote.c index 70f918a7362c..700e2c2b929f 1= 00644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -4776,6 +4776,8 @@ remote_target::start_remote_1 (int from_tty, int exte= nded_p) if (packet_support (PACKET_QAllow) !=3D PACKET_DISABLE) set_permissions (); + this->thread_events (1); + /* gdbserver < 7.7 (before its fix from 2013-12-11) did reply to any unknown 'v' packet with string "OK". "OK" gets interpreted by GDB as a reply to known packet. For packet "vFile:setfs:" it is an Using a test program similar to yours: $ ./gdb -nx -q --data-directory=3Ddata-directory a.out -ex "tar rem :1234= " -ex c ... leads to gdbserver crashing, the backtrace looks just like yours: =3D=3D33707=3D=3DERROR: AddressSanitizer: SEGV on unknown address 0x0000000= 00030 (pc 0x55d6edb7df07 bp 0x7fff852bc360 sp 0x7fff852bc350 T0) =3D=3D3370= 7=3D=3DThe signal is caused by a READ memory access. =3D=3D33707=3D=3DHint: address points to the zero page. #0 0x55d6edb7df07 in target_waitstatus::reset() /home/smarchi/src/binut= ils-gdb/gdbserver/../gdb/target/waitstatus.h:400 #1 0x55d6edbc6519 in target_waitstatus::operator=3D(target_waitstatus c= onst&) /home/smarchi/src/binutils-gdb/gdbserver/../gdb/target/waitstatus.h:= 187 #2 0x55d6edbb6bab in resume /home/smarchi/src/binutils-gdb/gdbserver/se= rver.cc:2931 #3 0x55d6edbb6523 in handle_v_cont /home/smarchi/src/binutils-gdb/gdbse= rver/server.cc:2875 #4 0x55d6edbb8129 in handle_v_requests(char*, int, int*) /home/smarchi/= src/binutils-gdb/gdbserver/server.cc:3138 #5 0x55d6edbc1844 in process_serial_event /home/smarchi/src/binutils-gd= b/gdbserver/server.cc:4484 #6 0x55d6edbc1a9b in handle_serial_event(int, void*) /home/smarchi/src/= binutils-gdb/gdbserver/server.cc:4516 #7 0x55d6edcdcef1 in handle_file_event /home/smarchi/src/binutils-gdb/g= dbsupport/event-loop.cc:574 #8 0x55d6edcdd82d in gdb_wait_for_event /home/smarchi/src/binutils-gdb/= gdbsupport/event-loop.cc:695 #9 0x55d6edcdb4f8 in gdb_do_one_event(int) /home/smarchi/src/binutils-g= db/gdbsupport/event-loop.cc:265 #10 0x55d6edbba12b in start_event_loop /home/smarchi/src/binutils-gdb/g= dbserver/server.cc:3514 #11 0x55d6edbbde10 in captured_main /home/smarchi/src/binutils-gdb/gdbs= erver/server.cc:3994 #12 0x55d6edbbe4b8 in main /home/smarchi/src/binutils-gdb/gdbserver/ser= ver.cc:4080 #13 0x7ff01623c28f (/usr/lib/libc.so.6+0x2328f) #14 0x7ff01623c349 in __libc_start_main (/usr/lib/libc.so.6+0x23349) #15 0x55d6edb59ec4 in _start ../sysdeps/x86_64/start.S:115 > So I went into *resume* and added the "cs.last_status.kind() !=3D TARGET_= WAITKIND_THREAD_EXITED) to the below code in that function as the "current_= thread->last_status" reference is the source of the segfault: > > if (cs.last_status.kind () !=3D TARGET_WAITKIND_EXITED > && cs.last_status.kind () !=3D TARGET_WAITKIND_SIGNALLED > && cs.last_status.kind () !=3D TARGET_WAITKIND_NO_RESUMED > && cs.last_status.kind () !=3D TARGET_WAITKIND_THREAD_EXITED) > current_thread->last_status =3D cs.last_status; I think that makes sense, as if linux-low.cc has reported TARGET_WAITKIND_T= HREAD_EXITED, it has deleted that thread_info, so current_thread will be ma= de nullptr. > After making this change, the server no longer crashes at the first=20 > thread exit, but instead, I get a packet that is > > w0;2635 > > Here's the problem though. When I receive the various "T05create;..." pa= ckets, the debuggee process is frozen. There's a bunch of printf's in my t= est app... and nothing happens until I issue the vCont back to the server.= On receipt of the w0;2635 packet, however, the process just keeps going..= . That is a bug, from what I understand. In all-stop, the target should all = threads whenever it returns any stop reply. This should be done by the "lo= w" target, linux-low.cc. Off-hand I don't understand why this call to stop= _all_lwps in linux_process_target::wait_1 doesn't stop the threads in that = situation: https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgitla= b.com%2Fgnutools%2Fbinutils-gdb%2F-%2Fblob%2Fe9a241e87b42f902d0408704df6bbc= d8bf465a46%2Fgdbserver%2Flinux-low.cc%23L3463&data=3D05%7C01%7Cwmessmer= %40microsoft.com%7C57a0cc725b7f47e2ae1108da95e12859%7C72f988bf86f141af91ab2= d7cd011db47%7C1%7C0%7C637987091529234592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC= 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&am= p;sdata=3DdAvf11H6aKpNyU7pWGu4LvF4Sh02mZpRLg1R2RIal0M%3D&reserved=3D0 > I suspect that's a bug in the gdbserver (I'm no expert here in either gdb= server or its code). That's the first question... and the second is wheth= er there's some other way that thread creations and exits get detected othe= r than QThreadEvents:1 (as this doesn't seem to be well supported). Yes, I think it's a bug. QThreadEvents should be the way to get notified a= bout thread creation / exit events as it happens. As mentioned earlier, it= 's only used when stopping all threads, at the moment. It's not enabled by= default because it would be inefficient when debugging applications with l= ots of short-lived threads. I think it's just that it has never been used = in all-stop mode yet, so you are the lucky one to stumble on those bugs. Simon