From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id AJ0UE9AqsWVpigYAWB0awg (envelope-from ) for ; Wed, 24 Jan 2024 10:20:48 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=oracle.com header.i=@oracle.com header.a=rsa-sha256 header.s=corp-2023-11-20 header.b=liDFSH3/; dkim=pass (1024-bit key; unprotected) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.a=rsa-sha256 header.s=selector2-oracle-onmicrosoft-com header.b=OhAYou0l; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 41FFC1E0C3; Wed, 24 Jan 2024 10:20:48 -0500 (EST) Received: from server2.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 ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C33C91E092 for ; Wed, 24 Jan 2024 10:20:45 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4C270385828F for ; Wed, 24 Jan 2024 15:20:45 +0000 (GMT) Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by sourceware.org (Postfix) with ESMTPS id 33A3A3858D37 for ; Wed, 24 Jan 2024 15:20:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 33A3A3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=oracle.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=oracle.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 33A3A3858D37 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=205.220.165.32 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1706109623; cv=pass; b=jijEsVCYN8BkvOys073FaW5Kl95UUbbzCWSc2dv7Jw+54hzicEmlozXGkJqwzOUJFA7SaibN4bVp3MBy4fqIuNSeXd/p5cQV4exORAWtn2mM5kikQY8CUVMjlO6XZHM+nN6Hb+uVck/w9WEYFfmLzFCPiWImbXon/wGjkwybpFo= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1706109623; c=relaxed/simple; bh=3XwB+L3hV5XWU60Tvzqwy2MWKphxN+4G3EMQSSAskIU=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:From:To: MIME-Version; b=hpWUvcguhwDA45qfRSxGX3zrVdF8j5S64pcaW72JHA05sTWKlBacEaXz6vr4aA9xhNzDqJmXg3MQRogWuGtJKZMz00sZvJ3PzJuKllLlTGil6aWBoI0r79PanEpoY681jb+bNLuJHlKvdKNc8u8LhHjia/Xnesvz6rBflUk/7Jk= ARC-Authentication-Results: i=2; server2.sourceware.org Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 40OEu5pJ016894; Wed, 24 Jan 2024 15:20:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=message-id : date : subject : from : to : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2023-11-20; bh=UiJRSlyPLVl6cRMbyZY7waDEIGWYX1Pf0Mkq9qpxymM=; b=liDFSH3/xICbqHABiw8Ej2V3vG8M/mDVvUbhqZAIXDfoZqYnD1iAKlAvlQnC3ls15Ki6 guZlTU+F+7mKDodW9GtcaW5qVP+q072bCEihNXmdELaMaYFPBSd5jCjH+v3NoN6ddBye EsAMAPcjsS58+di5A0b+HkNGWCBClHEjuxGjG/D10nJRuA8I7n4tFepZrr1RZdqd572V 8ylt1XRRZPkTuoZ1ybzSuQZRigEwjbdD60nRnJDESal7W360Sjr2euauyb6MwCLqyEGf kFOOu6g9usXbwUQXUkpT1WpJ9d11T6Q2mgDD7vrPCNHq8/yQC3YG4MOcenV71HKF9Hb4 mA== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3vr7anuycb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Jan 2024 15:20:08 +0000 Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 40OEfAuc003967; Wed, 24 Jan 2024 15:20:07 GMT Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2100.outbound.protection.outlook.com [104.47.55.100]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3vs32svg7r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Jan 2024 15:20:07 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aNwu+wAUiebvRfm64qGOGMlEWp7tt/pi0sW4FA0v8EGsxDGj1hCg6c+PjZKxrVhoX3rt51hlJgdWz46dLH24TuNZQ13HqPoweaU0As3L7MXZwum81wI62JJJBbFP6NSFkWSDRzNU+Qy4eOCuOwXYJYUf+FNNlopduTcvTLEbTiJvtUIIp4gbNw8LffSgfEd/v3gxui8+CPLoVzmouFIxeLgx+zBml9vQbKlBfWUgaD2RW4cw9nz2L+yqxcEkrGMrWirRbR0Bcsq0HsFCf12bfrJevU2SUX955ddcC4jOiQpCpmOeLlbyzRmVMsv5QQ+L++CMMAlhloKrz8rCR7wNXg== 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=UiJRSlyPLVl6cRMbyZY7waDEIGWYX1Pf0Mkq9qpxymM=; b=F2fCQpyYdu3rsFndZV2oPHcp88a5p09Jga9XIeUPgLZJZqc/3WnRiEPSb+ECrq6q/MfwRpdEdWIBrhmo63IUKZsHwRdVv7Tci2WETLSH3/I3HFyHcfBwp6fORtXq3g2rVaG6oFCJdKph2xVJlWjD+CW+MVMnBwrjL+u2mwksIdz4g0qxtkbtyXtaHOxCK9zne9KGRvt5QIUZwhWc4NGgKx0p+tR92KLD4RoPIU8cBf28GwZf0Y5sGGSOLxdrx42epbY7w0WgFiL9pnGjanlAdtmovlXwJMDQMBv3IOMDwCFLu3NRnoYp1VLUJq9b7dno0UORkGeBH1xrBAlyQafADQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UiJRSlyPLVl6cRMbyZY7waDEIGWYX1Pf0Mkq9qpxymM=; b=OhAYou0lvGaTAjMgcjuUjUxtJE8FpERgBt2b6VRvbrj0EqazGXN0bertssHDDiq6qhOhBPOruY06yGCPIZgYAM3AraeJ3gmHnbekYyxAOpxmCDF2SXcT309eCpWN7pRi3NLd3XRvhqtIIQzTHIi/pyJXyL+uovBGwttIs0q8cV4= Received: from DS7PR10MB4861.namprd10.prod.outlook.com (2603:10b6:5:3a7::15) by PH0PR10MB4773.namprd10.prod.outlook.com (2603:10b6:510:3e::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7228.22; Wed, 24 Jan 2024 15:20:04 +0000 Received: from DS7PR10MB4861.namprd10.prod.outlook.com ([fe80::9fd0:e664:32e6:2ec9]) by DS7PR10MB4861.namprd10.prod.outlook.com ([fe80::9fd0:e664:32e6:2ec9%6]) with mapi id 15.20.7228.023; Wed, 24 Jan 2024 15:20:04 +0000 Message-ID: Date: Wed, 24 Jan 2024 20:49:56 +0530 User-Agent: Mozilla Thunderbird Subject: Re: [External] : Re: [PATCH v3] gdb : Signal to pstack/gdb kills the attached process. Content-Language: en-US From: Partha Satapathy To: Guinevere Larsen , gdb-patches@sourceware.org, bert.barbe@oracle.com, rajesh.sivaramasubramaniom@oracle.com References: <123ee8d6-e6da-4227-ac7a-27d22041c20e@oracle.com> Organization: Oracle Corporation In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SI2PR02CA0027.apcprd02.prod.outlook.com (2603:1096:4:195::14) To DS7PR10MB4861.namprd10.prod.outlook.com (2603:10b6:5:3a7::15) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS7PR10MB4861:EE_|PH0PR10MB4773:EE_ X-MS-Office365-Filtering-Correlation-Id: 31829de9-0d63-48a2-9f6e-08dc1ceff099 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: M5TmlPjQveoS8ae1uwIBCst+u0o6bqTsBdzeqI/2BQodgJ4HE0IeD/u2NEXYtIPY46ewBOd0A0Aa10W1TJfyIyLP4+DaMqFbSE9Fxsh3olSXw61e0C5FYNLkmc0/kkRuLyfvDofNzsGLyt74cctWhU/S8B0wdj0ATcioM17ntL5GkOopygM/Wfp3bH9orp6vLxp+lGNKfb28FLvIMSt9Hae6OibmK8ScUhP1cHmPuiKsJyFGkYruVTtcfhtyo2L2QW46ecEZISrtMx5MWku8zZfqWimCrpRoalznM1oQyMqxmx1DyhmDZm+UCSRqsslcb7gwDl83dFI/od8N1efMtUPoQUT8ReiHQmpsLuoN5PiUfM6j34v+OglIi+ZIGuofz6Ky+ODjT8JfPg7Y/O63EvTvul5SKHFF5YLii4N9DVRWxxpPCX/hjeltEYK0JIgO1GoRULPARR3W5KOv6C4HYhII6v9E3YyQAp0tyMksDgmNkZQPOBnacsmRgA1kQ9eqzcrKFtZ22kkxR1y6LV/8mtZxkUU4mDneGtNltEA7oW7RifDoe1s8ylJnYkHrDZKO3oRe2t4hA2VkL/zAUzQ8V6ecmx9Ro4QP29O50MqafYnpADm3Y6V7JGxRU8bqlZvb8TdSYktu2yiHPYvCLwwWD77rI8ESj/TuaDWfkC2eGCsPrDNyfuHluM6i+5o9TMIs X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DS7PR10MB4861.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(376002)(136003)(346002)(39860400002)(366004)(396003)(230922051799003)(1800799012)(451199024)(186009)(64100799003)(6512007)(8676002)(8936002)(6506007)(53546011)(36916002)(36756003)(83380400001)(30864003)(2906002)(31696002)(2616005)(44832011)(5660300002)(26005)(478600001)(6486002)(41300700001)(966005)(86362001)(6666004)(6636002)(66946007)(66556008)(66476007)(316002)(31686004)(38100700002)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dHh1WG9CN0NXcGdubDBrRW01ZTF2Ri9VcDRLVGFIcFIvUkZFYVRwQVhzZE9p?= =?utf-8?B?U1V5d0lydWdLNzc0WUt2TjBDUVFmUE1kVXdQUW9MT0tza3Zud2ttQndGYklH?= =?utf-8?B?NlN2MEIzclZzV0ZYOFlIS3NUZGRZQTVvN2FVYnc3MERpenRTcjVOUHZLalRo?= =?utf-8?B?dXFqbnJqRjN3LzYzNmdSdzJTTjd4bE5Gbk50V0svU242dVZ2UGpzYTRZSWJm?= =?utf-8?B?bURWUHVIK3lmSm9vc0Fka3hHSkhMZ05kNUhITS9QSllnY1BFeDJpNEhLOVJN?= =?utf-8?B?djJPTGo2dUtobzNKSzFWc09jcHN0eDVFdGZsTzFSdkE2Tmw2alpmNm5sQlV0?= =?utf-8?B?b0FoV1RPMG5IUURiczRpL3VvUWhzM0hqSVRCQW0rUUg2U2UwZEwvbzRBRmJu?= =?utf-8?B?bnJOZkxHeDR1aFJmeHllWmdNZVkrRmZaYks1K0tKbFIyUjZqQ2g0M3dhTTRW?= =?utf-8?B?T0EzT2NSWGNRL0dtOS8zUkRoZzQwUzIxeUhSVUcrYTJpVUFselR4a0wrZWx5?= =?utf-8?B?UXBSN2FlUEQxUDNMbFZ4eHBNWTZ6WGN4MmxhQXBheWY1RFAyL290UURVUmhQ?= =?utf-8?B?dmpWRyt6cG1jL25IV1JrV0lmYW81STRlN1JpL1BVSmszVWpxSHFHMnVNM0M3?= =?utf-8?B?R2d1MmdBcE9DZXcrNDQvNnRubk92dlhpa0kwdWFlVzhEMEZzK1lCRWovZjB3?= =?utf-8?B?bzNGaTZjMUo1aE9MS0s0c2tRRlcra0VaeU4vRUNmRDIzMEtRMmcwaGlTRjEx?= =?utf-8?B?VFZhc1Iwa29XNDQ5aEdoZkJDeDVudjl0NDhKcFEwS0ZuK05LZzdlcG5ISXh1?= =?utf-8?B?emUvSTAwY09OZnhWRGxSMTl5QndPaGNzaXhsZjE0T21WbmlscWhkWENXN2hV?= =?utf-8?B?dmcrWlZsSHVKTyttMzUydmZQV3Y4RGtLR2MrOXRWUFVod1FsUzFOcm94V0ZH?= =?utf-8?B?WHJ4OWtBQ1kvTXYzSE83UlNEemNUZlA1bmxWNHV6WEdkMHUweEdJY0xQRVc3?= =?utf-8?B?U1ZwYWJyeC9aNVdQS0VyYmZjaEVEMFQzNnNMTVNZWXovMENxWEptK0RRQjdM?= =?utf-8?B?QWNzblRqZzUzeUhFVUpTWDRLNDBlUm41b1IxcWtMSGhmMXEvS1ltOTdXWGps?= =?utf-8?B?NjRRQmNVSjRRRHNyY0tOcm5HVy90Q3NNaVVBUmhkL0ljcHhqWnAveFM2N3lV?= =?utf-8?B?blV1OXVnZkFJSlBDRXdQdms1Wjd4dFZTd2RhQURxNjFNRjhWY1pLQ0t6WWNO?= =?utf-8?B?d2pDZmdRekkvVzY3WWkxNEsyaFIwOFczR2dIbS9BbUZxY3l4bldaUTQ5UE94?= =?utf-8?B?SHUvanVSQm5vMkpteGVuZWY1L1pDU1V4N0lMcE5QL0c4eEpGZ3g4ZndreFdM?= =?utf-8?B?TnMwWk5LZWVMa0cyREc0NWo1azlmbG1uTmNNekhaQ1M1RW84VWN2OFpvMFlW?= =?utf-8?B?aWszMnVYOTB6cEhoMzJSTGZJUE4xdXFDMW1sU3NQQkVGdXFkRS8zRlBtV2lM?= =?utf-8?B?aEFCbFA5aTdseFhXemowbGRCVHlCM2NtMFNCNXlHWkQwQWZheEpvUU9FMU9x?= =?utf-8?B?VTlRbGU3bzViVU9IZm5ZRXY5TStCV3Flak5na3JTU0liV0gvZzQvNHN0WEFs?= =?utf-8?B?SlJ5eUZBdk43My9yUzFPZ2lZUGcyV3Yza1ZqL0Zwemp2MFR1UUVnQzU1ZExQ?= =?utf-8?B?c0ZEZmFFK3Z4bmtZUjFkY1hlUjFmV2s0QTBGcGEwd2lidy9tNTg5dFBoQTl2?= =?utf-8?B?bXFqTXJVK2RjS0o2aTR5ZUhRT3FUNHltYVdSc1VTTXdzdE95cHhjRm9nOEQ5?= =?utf-8?B?NUFWRjJZcTA1SmFiUGRSZnVwV29OL09rUFAyc2o4NmNlN2s0VmduWGQ0K3Uy?= =?utf-8?B?a045allURTJhYmJ1MWp5WU1oTlRrdUdmcFpGWlU0czZ0aFZDTXdzaUhRZ09Q?= =?utf-8?B?bTZtZC9kdUlRb2F1NVN6TURLeWxFcy9NTmRwNVJUcllMU2krSHIwQ0MzSmpB?= =?utf-8?B?cTNMMXRINGpOWGtHRjhvV3VreDhPeFVOU0ZkTVpsQkkwNU84KzZEUmNmZ3Zy?= =?utf-8?B?ZWtZR1RLc2VXVnBCZ0JNN0dhanoyZ2NITzNoV2phZ1dMa3M1RlF0YXYybEIz?= =?utf-8?B?bkRuTDNDS1d3dTBTYjNvdUNqbERsV0tyZkRZMG1GUTgzbExUM0dQRWN3WmRV?= =?utf-8?B?T1E9PQ==?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 6oDY+16R53x16l2N11Az53r3d2Saf2f2LRb2qVuDWNg4lCgESaG50Pg1kyAh6jgrQhuTw9m0hTRQMkh8QdAxLUGFs2j50GrUVDXckoRqzigtv1woamnpJ3zKSTO6Ook5XHUlPE9Z/HqRAVEZFEaQT4bt4s2aYVIxjfWEwyoL9KJwwOb7f5sLTHJuMh+cA/Vb+kOGYlAFw9o6urWDGvqnPGP9s8kQdLmLDVP+7m8I1UhJwESZ6MiAVXpZk+gr1k2dSvSyo4U8+wVJkp4UjNktprgWbp6DxAgjlTOMzIln9QqKnZMk1L046/ccnryGoMX4IcJO/otKGseRWGUmvEd77kIN6N9jeAGKPvwSrtvnT31nIVLEqeFIg1bzZKfHgpFLLGoGOgMxVTWIIpW4OOs7OQ5T46/DXx5yhvzqH7m3kJNzBh1Cy0MUdlT8IsXTUtdSTs8AbSMcvv+OeCOq6gEgUZNs3kkKNMUE/oWtkv2e3mipix/+1Jnz58hhPmIT9I1IedEk30VusfpA5i/fYpz/f+m/kihASi5LMOUv85QjhBzgTaBw4prb2TrP65BK8G1nS71T5npxu1LRnOW4RBHmjW6NS96cBip1slmnEWWpjpM= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 31829de9-0d63-48a2-9f6e-08dc1ceff099 X-MS-Exchange-CrossTenant-AuthSource: DS7PR10MB4861.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jan 2024 15:20:04.2272 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: CyZcf80hM4klfgYgi1aivRSjKKbc+RZagOOM5Oawek5hyNhvwzpT5NaJD6OlPgxEdqfitZnn278kjaouRHns5Gg5jz17yncm9Gqn78Np38Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR10MB4773 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-24_06,2024-01-24_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=999 spamscore=0 mlxscore=0 adultscore=0 bulkscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2401240111 X-Proofpoint-GUID: tznsBV1P_I9Uiq82Fn3mJ4DZ6Z74jBnr X-Proofpoint-ORIG-GUID: tznsBV1P_I9Uiq82Fn3mJ4DZ6Z74jBnr X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, TXREP, T_SCC_BODY_TEXT_LINE, T_SPF_TEMPERROR autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org On 1/10/2024 9:29 PM, Partha Satapathy wrote: > On 12/5/2023 6:43 PM, Guinevere Larsen wrote: >> On 17/11/2023 15:48, Partha Satapathy wrote: >>> On 11/6/2023 7:08 PM, Guinevere Larsen wrote: >>>> On 02/11/2023 19:27, Partha Satapathy wrote: >>>>> On 11/2/2023 11:54 PM, Partha Satapathy wrote: >>>>>> On 10/25/2023 9:24 PM, Guinevere Larsen wrote: >>>>>>> Hi! >>>>>>> >>>>>>> Thanks for working on this issue, and sorry about the delay in >>>>>>> getting this reviewed. For future reference, we (at least I) tend >>>>>>> to try and go for patches with many pings, so it is better to >>>>>>> ping existing patches than re-sending them :) >>>>>> >>>>>> I some how missed this mail, hence a delay in reply. >>>>>> I sorry for this and unfortunately have made the mistake once again. >>>>>> Hope the extra threads can be deleted and I will keep my >>>>>> discussion bound to this thread. >>>>>> >>>>>>> >>>>>>> I'm not very knowledgeable on how GDB does signal handling, so >>>>>>> I'm going to review this patch at face value. I hope someone who >>>>>>> does know how this part works gets a look at this soon! >>>>>>> >>>>>>> On 16/10/2023 11:28, Partha Satapathy wrote: >>>>>>>> Problem : >>>>>>>> While gdb attaching a target, If ctrl-c pressed in the midst of >>>>>>>> the process attach,  the sigint is passed to the debugged >>>>>>>> process. This triggers exit of the debugged. >>>>>>>> >>>>>>>> Let’s take the example of pstack,  which dumps the stack of all >>>>>>>> threads in a process. In some cases printing of stack can take >>>>>>>> significant time and ctrl-c is pressed to abort pstack/gdb >>>>>>>> application. This in turn kills the debugged process, which can >>>>>>>> be critical for the system. In this case the intention of >>>>>>>> “ctrl+c” to kill pstack/gdb, but not the target application. >>>>>>>> >>>>>>>> Reproduction: >>>>>>>> >>>>>>>> The debugged application generally attached to process by: >>>>>>>> gdb -p <> >>>>>>>> or gdb /proc/<>/exe pid >>>>>>>> pstack uses the latter  method to attach the debugged to gdb. If >>>>>>>> the application is large or process of reading symbols is slow, >>>>>>>> gives a good window to press the ctrl+c during attach. Spawning >>>>>>>> "gdb" under "strace -k" makes gdb a lot slower and gives a >>>>>>>> larger window to easily press the >>>>>>>> ctrl+c at the precise period i.e. during the attach of the debugged >>>>>>>> process. The above strace hack will enhance rate of reproduction >>>>>>>> of the issue. Testcase: >>>>>>>> >>>>>>>> With GDB 13.1 >>>>>>>> ps aux | grep abrtd >>>>>>>> root     2195168   /usr/sbin/abrtd -d -s >>>>>>>> >>>>>>>> #strace -k -o log gdb -p 2195168 >>>>>>>> Attaching to process 2195168 >>>>>>>> [New LWP 2195177] >>>>>>>> [New LWP 2195179] >>>>>>>> ^C[Thread debugging using libthread_db enabled] >>>>>>>> <<<<   Note the ctrl+c is pressed after attach is initiated and >>>>>>>> it’s >>>>>>>> still reading the symbols from library >>>> Using host >>>>>>>> libthread_db library "/lib64/libthread_db.so.1". >>>>>>>> 0x00007fe3ed6d70d1 in poll () from /lib64/libc.so.6 >>>>>>>> (gdb) q >>>>>>>> A debugging session is active. >>>>>>>>           Inferior 1 [process 2195168] will be detached Quit >>>>>>>> anyway? (y or n) y Detaching from program: /usr/sbin/abrtd, >>>>>>>> process 2195168 >>>>>>>> >>>>>>>> # ps aux | grep 2195168 >>>>>>>> <<<< Process exited >>>> >>>>>>>> >>>>>>>> Description: >>>>>>>> >>>>>>>> We are installing a signal handler in gdb that marks the >>>>>>>> Ctrl-c/sigint received by gdb. GDB passes this sigint to the >>>>>>>> debugged at some definite points during the window of process >>>>>>>> attach. The process of attaching debugged involves steps like >>>>>>>> PTRACE_ATTACH , reading symbols, getting the stop signal from >>>>>>>> the debugged and get ready with GDB prompt. Note: >>>>>>>> one of the example of this is sigint passing is: >>>>>>>> "     - 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. >>>>>>>> " >>>>>>>> >>>>>>>> There are few other places where sigint is passed to the >>>>>>>> debugged during attach of process to gdb. As the debugger and >>>>>>>> debugged are not fully attached during this period, the sigint >>>>>>>> takes its default action and terminates the process. >>>>>>>> >>>>>>>> Solution: >>>>>>>> >>>>>>>> While gdb attaches process, the target is not the current >>>>>>>> session leader. Hence, until attach is complete and GDB prompt >>>>>>>> is availed, the sigint should not be passed to the debugged. A >>>>>>>> similar approach is taken for "gdb) run &". In >>>>>>>> target_terminal::inferior() >>>>>>>>     /* A background resume (``run&'') should leave GDB in >>>>>>>> control of the >>>>>>>>        terminal.  */ >>>>>>>>     if (ui->prompt_state != PROMPT_BLOCKED) >>>>>>>>       return; >>>>>>>> >>>>>>>> The passing of signal is skipped if the process ran in >>>>>>>> background. With this approach we can skip passing the sigint if >>>>>>>> the process is attached to gdb and process attach is not complete. >>>>>>>> Here is the proposed solution: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Fix : >>>>>>>> >>>>>>>> While gdb attaching a target, If ctrl-c/sigint pressed in the >>>>>>>> midst of the process attach, the sigint is passed to the >>>>>>>> debugged process. >>>>>>>> This triggers exit of the debugged. >>>>>>>> >>>>>>>> This issue is evident while getting the process stack with ./gdb >>>>>>>> --quiet -nx  -ex 'set width 0' -ex 'set height 0' >>>>>>>> -ex 'set pagination no' -ex 'set confirm off' >>>>>>>> -ex 'thread apply all bt' -ex quit /proc//exe and >>>>>>>> press the ctrl+c while attach. >>>>>>>> >>>>>>>> The above method is also used in pstack application which is a >>>>>>>> wrapper over gdb to print the process stack. A Ctrl+C intended >>>>>>>> to kill gdb or pstack, but kills the debugged even if it is >>>>>>>> attached and not spawned by gdb. >>>>>>> >>>>>>> This is a very good description of the error you've encountered, >>>>>>> but given the repetition on this "fix:" part, I'm wondering, what >>>>>>> is meant to be the commit message? Is it just these last few >>>>>>> lines, or is it the whole thing? If it is just this last bit, I >>>>>>> think it would benefit from some more explanation of the >>>>>>> solution. If it is the whole message, I think you can reduce a >>>>>>> bit the repetition. >>>>>>> >>>>>>> Also, at many points you say "debugged process" and "target". In >>>>>>> GDB-land we call that the "inferior". Target has a very specific >>>>>>> meaning in the context of GDB (roughly the CPU you're running, >>>>>>> and some extra bits here and there). >>>>>>> >>>>>>> I also have a few comments on the specific changes, that are >>>>>>> inlined. >>>>>>> >>>>>>>> --- >>>>>>>>   gdb/inferior.h | 3 +++ >>>>>>>>   gdb/target.c   | 4 ++++ >>>>>>>>   gdb/top.c      | 2 ++ >>>>>>>>   3 files changed, 9 insertions(+) >>>>>>>> >>>>>>>> diff --git a/gdb/inferior.h b/gdb/inferior.h index >>>>>>>> 4d001b0ad50e..b7048d10bbe4 100644 >>>>>>>> --- a/gdb/inferior.h >>>>>>>> +++ b/gdb/inferior.h >>>>>>>> @@ -557,6 +557,9 @@ class inferior : public refcounted_object, >>>>>>>>     /* True if this child process was attached rather than >>>>>>>> forked.  */ >>>>>>>>     bool attach_flag = false; >>>>>>>> >>>>>>>> +  /* True if target process synced and gdb ui is out of block. >>>>>>>> */ bool >>>>>>> >>>>>>> This comment is oddly worded. Based on the change to gdb/top.c, I >>>>>>> think you could reword it like this: >>>>>>> >>>>>>> /* True if inferior has been fully synced and the prompt is no >>>>>>> longer blocked.  */ >>>>>>> >>>>>>>> + sync_flag = false; >>>>>>> Typo here, the variable's type should be on this line. >>>>>>>> + >>>>>>>>     /* If this inferior is a vfork child, then this is the >>>>>>>> pointer to >>>>>>>>        its vfork parent, if GDB is still attached to it.  */ >>>>>>>>     inferior *vfork_parent = NULL; >>>>>>>> diff --git a/gdb/target.c b/gdb/target.c index >>>>>>>> d5bfd7d0849b..f7c115497451 100644 >>>>>>>> --- a/gdb/target.c >>>>>>>> +++ b/gdb/target.c >>>>>>>> @@ -3826,6 +3826,10 @@ target_pass_ctrlc (void) >>>>>>>>                   through the target_stack.  */ >>>>>>>>                scoped_restore_current_inferior restore_inferior; >>>>>>>>                set_current_inferior (inf); >>>>>>>> +             if ((current_inferior()->attach_flag) && >>>>>>> >>>>>>> A couple of style issues here: when the indentation would have 8 >>>>>>> spaces, you should use a tab instead; >>>>>>> >>>>>>> There should be a space between the function name and the >>>>>>> parameters; >>>>>>> And when you need to cut a logical expression in half, the >>>>>>> operator should be at the start of a new line. >>>>>>> >>>>>>>> + !(current_inferior()->sync_flag)) { >>>>>>> In this case, since it is just one line, there is no need to have >>>>>>> the curly braces. However, when they are needed, they should be >>>>>>> on the following line, and 2 spaces further in indentation. >>>>>>>> + return; >>>>>>>> +             } >>>>>>>>                current_inferior ()->top_target ()->pass_ctrlc (); >>>>>>>>                return; >>>>>>>>              } >>>>>>>> diff --git a/gdb/top.c b/gdb/top.c >>>>>>>> index 621aa6883233..26cc6caac0e5 100644 >>>>>>>> --- a/gdb/top.c >>>>>>>> +++ b/gdb/top.c >>>>>>>> @@ -542,6 +542,8 @@ wait_sync_command_done (void) >>>>>>>>     while (gdb_do_one_event () >= 0) >>>>>>>>       if (ui->prompt_state != PROMPT_BLOCKED) >>>>>>>>         break; >>>>>>>> + >>>>>>>> +  current_inferior()->sync_flag = true; >>>>>>> >>>>>>> I'm not very knowledgeable on this part of GDB, so take this with >>>>>>> a grain of salt, but I wonder if this is the best place to put this. >>>>>>> >>>>>>> Since you only set this flag as false when first creating the >>>>>>> inferior structure, I don't see why it should be re-set every >>>>>>> time we're waiting for a command to be done. You could set the >>>>>>> sync flag to false every command, but that feels like overkill. I >>>>>>> feel like there should be some a mechanism in GDB already that >>>>>>> knows if we're the session leader or not, and thus handles things >>>>>>> correctly, but I don't know what it is. >>>>>>> >>>>>>> Another possibility, based on the exact problem you had, is to >>>>>>> put this at the end of either symbol expansions, or the reasons >>>>>>> they are being expanded in the first place (which I suspect is >>>>>>> something like trying to identify the language or name of the >>>>>>> main function). >>>>>>> >>>>>> >>>>>> wait_sync_command_done() is not frequently called with command >>>>>> execution. >>>>>> strace -k -o log ./gdb -p <> >>>>>> (gdb) ls >>>>>> Undefined command: "ls".  Try "help". >>>>>> (gdb) !ls >>>>>> (gdb) disassemble main >>>>>> >>>>>> confirmed the function wait_sync_command_done() is not part of >>>>>> this trace. wait_sync_command_done() is called from >>>>>> run_inferior_call() >>>>>> and serve as inferior startup and wait for it to stop. >>>>>> >>>>>> /* Subroutine of call_function_by_hand to simplify it. >>>>>>     Start up the inferior and wait for it to stop. >>>>>>     Return the exception if there's an error, or an exception with >>>>>>     reason >= 0 if there's no error. >>>>>> >>>>>>     This is done inside a TRY_CATCH so the caller needn't worry about >>>>>>     thrown errors.  The caller should rethrow if there's an >>>>>> error.  */ >>>>>> >>>>>> static struct gdb_exception >>>>>> run_inferior_call (std::unique_ptr sm, >>>>>>                     struct thread_info *call_thread, CORE_ADDR >>>>>> real_pc) >>>>>> { >>>>>> >>>>>>        /* Inferior function calls are always synchronous, even if the >>>>>>           target supports asynchronous execution.  */ >>>>>>        wait_sync_command_done (); >>>>>> >>>>>> So wait_sync_command_done called once per inferior at startup. >>>>>> >>>>>> >>>>>> Hi Guinevere, >>>>>> >>>>>> Thanks for the review and sorry for the delay in reply. >>>>>> Please find comments inline. >>>>>> >>>>>> I will send the V2 incorporating rest of the comment. >>>>>> >>>>>> Thanks >>>>>> Partha >>>>> >>>> Hi! Thanks for the updated version. It looks much better! >>>> >>>> However, I still cant apply the patch. Are you sure you're >>>> developing on the master branch of our upstream repository? >>>> (https://urldefense.com/v3/__https://sourceware.org/git/binutils-gdb.git__;!!ACWV5N9M2RV99hQ!N_X8-tLG80n66yoOg95U0435CrvbbnDiHbebshHmNxivPGKLL5ZTy2le27VURzCGpKU6zzBqP4Jtu3d5km1jRA$ ) >>>> >>>> I have been manually changing the source code to test the patch, but >>>> it should cleanly apply for other maintainer to have an easier time >>>> reviewing things. >>>> >>>>> >>>>> Problem: While gdb is attaching an inferior, if ctrl-c is pressed >>>>> in the >>>>> middle of the process attach,  the sigint is passed to the debugged >>>>> process. This triggers the exit of the inferior. For example in >>>>> pstack, >>>>> printing a stack can take significant time, and ctrl-c is pressed to >>>>> abort the pstack/gdb application. This in turn kills the debugged >>>>> process, which can be critical for the system. In this case, the >>>>> intention of ctrl+c is to kill pstack/gdb, but not the inferior >>>>> application. >>>>> gdb -p <> >>>>> or gdb /proc/<>/exe pid >>>>> Attaching to process >>>>> << ctrl+c is pressed during attach >>>>> (gdb) q >>>>> <<<< inferior process exited >>>> >>>>> >>>>> A Ctrl-C/sigint received by gdb during the attachment of an inferior >>>>> passed to the debugged at some definite points during the window of >>>>> process attachment. The process of attaching an inferior is a >>>>> multistep >>>>> process, and it takes time to get ready with the GDB prompt. As the >>>>> debugger and debugger are not fully attached during this period, the >>>>> sigint takes its default action to terminate the process. >>>>> >>>>> Solution: While GDB attaches processes, the inferior is not the >>>>> current >>>>> session leader. Hence, until attach is complete and the GDB prompt is >>>>> available, the sigint should not be passed to the inferior. >>>>> The signal should be skipped if the process runs in the background. >>>>> With >>>>> this approach, we can skip passing the signature if the process is >>>>> attached to the GDB and the process attach is not complete. >>>>> --- >>>>>  gdb/inferior.h | 3 +++ >>>>>  gdb/target.c   | 4 ++++ >>>>>  gdb/top.c      | 2 ++ >>>>>  3 files changed, 9 insertions(+) >>>>> >>>>> diff --git a/gdb/inferior.h b/gdb/inferior.h >>>>> index 4d001b0ad50e..d5d01bd0d09c 100644 >>>>> --- a/gdb/inferior.h >>>>> +++ b/gdb/inferior.h >>>>> @@ -557,6 +557,9 @@ class inferior : public refcounted_object, >>>>>    /* True if this child process was attached rather than forked. */ >>>>>    bool attach_flag = false; >>>>> >>>>> +  /* True if inferior has been fully synced and prompt is no >>>>> longer blocked.  */ >>>>> +  bool sync_flag = false; >>>>> + >>>>>    /* If this inferior is a vfork child, then this is the pointer to >>>>>       its vfork parent, if GDB is still attached to it.  */ >>>>>    inferior *vfork_parent = NULL; >>>>> diff --git a/gdb/target.c b/gdb/target.c >>>>> index d5bfd7d0849b..4eff3130bad7 100644 >>>>> --- a/gdb/target.c >>>>> +++ b/gdb/target.c >>>>> @@ -3826,6 +3826,10 @@ struct target_ops * >>>>>                  through the target_stack.  */ >>>>>               scoped_restore_current_inferior restore_inferior; >>>>>               set_current_inferior (inf); >>>>> +             if ((current_inferior ()->attach_flag) >>>>> +                 && !(current_inferior ()->sync_flag)) >>>>> +                   return; >>>> also, there's still 8 spaces here. All 8 space-identations should be >>>> replaced with tabs. >>>>> + >>>>>               current_inferior ()->top_target ()->pass_ctrlc (); >>>>>               return; >>>>>             } >>>>> diff --git a/gdb/top.c b/gdb/top.c >>>>> index a685dbf5122e..f05fdd161a42 100644 >>>>> --- a/gdb/top.c >>>>> +++ b/gdb/top.c >>>>> @@ -542,6 +542,8 @@ struct ui_out ** >>>>>    while (gdb_do_one_event () >= 0) >>>>>      if (ui->prompt_state != PROMPT_BLOCKED) >>>>>        break; >>>>> + >>>>> +  current_inferior ()->sync_flag = true; >>>> >>>> I'm still not 100% convinced this is the best place to put this. >>>> Mainly because this function is also called by >>>> maybe_wait_sync_command_done; it didn't show up in your testing >>>> because when we run gdb from a terminal, the UI is synchronous (so >>>> it fails the first part of the IF condition), but this would be >>>> exercised in other situations. And maybe_wait_sync_command_done is >>>> called after every single command. >>>> >>>> I tried adding this to setup_inferior, which looked like the perfect >>>> place for it, but it unfortunately didn't work. Since done is better >>>> than perfect, I'm not going to block this patch on this, but I'd >>>> love to see a more logical place for this code. >>>> >>> >>> Hi Guinevere, >>> >>> Can't agree more on setup_inferior is the best place to reset this >>> variable. Updated V3 of review accordingly. Added a check_quit_flag >>> which will clear quit_flag, if set before setup_inferior. >>> >>> >>> Author: Partha Sarathi Satapathy >>> Date:   Fri Nov 17 11:42:11 2023 +0000 >>> >>> gdb : Signal to pstack/gdb kills the attached process. >>> >>> Problem: While gdb is attaching an inferior, if ctrl-c is pressed in the >>> middle of the process attach,  the sigint is passed to the debugged >>> process. This triggers the exit of the inferior. For example in pstack, >>> printing a stack can take significant time, and ctrl-c is pressed to >>> abort the pstack/gdb application. This in turn kills the debugged >>> process, which can be critical for the system. In this case, the >>> intention of ctrl+c is to kill pstack/gdb, but not the inferior >>> application. >>> gdb -p <> >>> or gdb /proc/<>/exe pid >>> Attaching to process >>> << ctrl+c is pressed during attach >>> (gdb) q >>> <<<< inferior process exited >>>> >>> >>> A Ctrl-C/sigint received by gdb during the attachment of an inferior >>> passed to the debugged at some definite points during the window of >>> process attachment. The process of attaching an inferior is a multistep >>> process, and it takes time to get ready with the GDB prompt. As the >>> debugger and debugger are not fully attached during this period, the >>> sigint takes its default action to terminate the process. >>> >>> Solution: While GDB attaches processes, the inferior is not the current >>> session leader. Hence, until attach is complete and the GDB prompt is >>> available, the sigint should not be passed to the inferior. >>> The signal should be skipped if the process runs in the background. With >>> this approach, we can skip passing the signature if the process is >>> attached to the GDB and the process attach is not complete. >> >> Hi! >> >> Sorry about the delay on this. I think this is patch looks good to me, >> Reviewed-By: Guinevere Larsen >> >> I hope some maintainer for this area look at this soon! >> > > Hi Team, > > Great if we can get a update on further proceedings on this. > > Thanks > Partha Hi Guinevere and Team, Great if we can have further update on this. One more thing notice the online thread for this issue: https://sourceware.org/pipermail/gdb-patches/2023-November/204251.html is missing last couple of communications. Thanks Partha