From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id tjEbHebi0mXoXSMAWB0awg (envelope-from ) for ; Mon, 19 Feb 2024 00:11:02 -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=Mch4R5Hh; 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=c64Gm/Q0; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 640B61E0D2; Mon, 19 Feb 2024 00:11:02 -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 07EE11E092 for ; Mon, 19 Feb 2024 00:11:00 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4D2F53861816 for ; Mon, 19 Feb 2024 05:10:59 +0000 (GMT) Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by sourceware.org (Postfix) with ESMTPS id EC486385801C for ; Mon, 19 Feb 2024 05:10:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EC486385801C 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 EC486385801C Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=205.220.177.32 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1708319439; cv=pass; b=jx8qEZzcx7KZ4PTa5wgM9WEi1JHyx5DDYOs8q/ElGcj1hNenWnTx36TP/WGNROkejdOwA/faNWMlpPRZ50+bhU0iT3LxyvziO/0j+PzzjphUikiUV/ShxP9U+jOKh4Ca4q8/fSz4qxt3Gww445UfULgm9/sPoAX32ZCRs4DG7ik= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1708319439; c=relaxed/simple; bh=qlg/M2kzIE1xOBQOBwXQ3fBCYYBeEBG6A/aG0aouSrw=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:From:To: MIME-Version; b=qYFRRQdQl9R2hUYs8QCoViH7rvLGRJH71ZSbljOt/9dqfb9yh4ouF+LdrMH4o5djhr7soUurQQ0aCl5h5djAERFKXDplJFGtcBHzkxA9EY48Y2Cg2aN9Hr4Hf8fb/naCqoIzTrsFGfbIiSfLMMLlFmJx0TrFAvpIl30yA0asXFw= ARC-Authentication-Results: i=2; server2.sourceware.org Received: from pps.filterd (m0333520.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 41INWKVR029246; Mon, 19 Feb 2024 05:10:33 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=3Lfwx+imWd4aeu6EXosxSu/XLY6Nodg1eqrU91ai2hY=; b=Mch4R5HhhT+2Cy/Es0np1qTWB//49ox+qhhNInNZ6pEYw53c0rigKt2IgVGrCVu7yc1N LeD3x9+f2I/pC4WC+z4o3DYeQ9fYXZsmz190eqe5yMCVMGLRRZLWLOd7e3UJEb1zXHne uLFzW9tftzLyz+1hORmxthrz5ipL1hg4cJmlqweL+8bstKbEwH2oqaQww17ApzuAAtMO jwrDlFbUE7hqJHCCAcY7hu0AnXKJh9PpRElaqersC6d2kOG4BdXhvCs4WlEJ1DHYL7Jy p3d/rNOsNbxb5ksSdVMIgi+RVERZ9Tg/jl9Bye/lFLB7yAlIQkf7ZhsNbukqQQRC3PJk zA== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3wamucu57j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Feb 2024 05:10:32 +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 41J4hQEL000781; Mon, 19 Feb 2024 05:10:32 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2100.outbound.protection.outlook.com [104.47.70.100]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3wak85cv1a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Feb 2024 05:10:32 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hHuQXpgV3atOFh2+YStmh50h6nmTRg4T0OCiBqCduU6K9/FLEUvJ3JdJBptEcNOino4TuNBz4tEEu7IF/vcNPhf2i6+gr5L7uyCMaBSwXiXuh7vSGGI0Zttm4GdfdxE/oRdeAJYPX/RIznirSJb9k9PuVAGrEqDJbuL71oC2sdmD5RsuPFD0nsBwrWLr0V18uF7Ur6bgeSIhEKVnxP73iAi5SwllYDGci8YmyYcXX7YU9k5/zLJg+v0yhKxLblT8G39P5C9wjgeYcvP+P9/DdUmqK2Chb8OWfrst3IA4G0IyJMsa7Hx5SjzPZumgVRYa7ayy27oEOBoxKe4/I2KSGw== 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=3Lfwx+imWd4aeu6EXosxSu/XLY6Nodg1eqrU91ai2hY=; b=beP+3JwJyQXxA3F2vE7f/jEEBUdYvGlvMk7g5b0z2dQeG742SVUrEzoPU8Jcbkt4Yj76u49MhJ0L15cv6T+C6B5HXj4Wo/JZlP8nmG2/5iYbD+4j8FjvVNxS61btAGKHxpTUaiOaYumAcrc404VB09NFjaoxlNLJ9/6j6XxG0ZH6FT2M6dtKmfN+nSYUVBwTndx3QAVWfzPtLAbTZklEfdwC6KbNkhNTFnKMhXpc7OJTIjwZI3a0Si4Qn689tNSyAaOb1ykoGdGaeM/QasTdct1VcLCzDdNcNt4N1XDuHeMNRajzXhqktrkQEMmFq6tVFGlYRuRtjYmIqOKYw7FcVg== 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=3Lfwx+imWd4aeu6EXosxSu/XLY6Nodg1eqrU91ai2hY=; b=c64Gm/Q0IwdV+L9NMjpwHOQjoki/taSwSitKFkKCbhtr6SNMX0lurZBuI/NCynCIdo6FU2tKssXSlS/tScGo2FWcvGyQFbwYlYHpBFUjW2rCXpisV+W2xApX7ZIwFzB++x3OtrpGSjthGaoBxy2XRDCGcvNm6rdoHFQrke07H/Y= Received: from DS7PR10MB4861.namprd10.prod.outlook.com (2603:10b6:5:3a7::15) by BN0PR10MB5094.namprd10.prod.outlook.com (2603:10b6:408:129::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7292.38; Mon, 19 Feb 2024 05:10:30 +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.7292.036; Mon, 19 Feb 2024 05:10:30 +0000 Message-ID: Date: Mon, 19 Feb 2024 10:40:22 +0530 User-Agent: Mozilla Thunderbird Subject: Re: [External] : Re: [PATCH v3] gdb : Signal to pstack/gdb kills the attached process. 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> Content-Language: en-US Organization: Oracle Corporation In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SI2PR01CA0050.apcprd01.prod.exchangelabs.com (2603:1096:4:193::21) To DS7PR10MB4861.namprd10.prod.outlook.com (2603:10b6:5:3a7::15) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS7PR10MB4861:EE_|BN0PR10MB5094:EE_ X-MS-Office365-Filtering-Correlation-Id: c303e97c-ce3c-43db-a34c-08dc31091768 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: S6N6g3KAZdhCdS7/ashWAbGHNdzNaOSvUisKeZdwy/Lmsi3bDNS3eWJug7W7jRSAwFeKpZ+IH11gu6FwbDt6nNEyseNzeWJEUofgTObpd/thX9p/Rekb8doQcGKQZ+jGi/AaRcWTdDYT7P+GlvmD57WZqpwvippB3g/jC8gVwV0w+DdIb/W0p06eoqo3B7ra/792P2f71uTvelMPc7KlKhSABqWAiMC8TAckKa3CGBi2LuRdyVBflBwLXmBr8Znv80o2UPxAnStjXmsuchjQ1L1jyv+b31UaKc4rh0QJpBwb5BXOQL0ObhOB+LyOGlEKHaeQzC9nda+WO4cjoHFYw5Unzq72lRq49Nn1C6cO/AMNZwOjFNBrD0aZKA6dCgtEErqGEvtonseZ9muWs+qZjMrOmfwt1FptC83Pl4R0i6P0Rhnse0xUprZxpl2BuWw8HaNu3zQTlDW+LhC9VyxwxrcbJHYVCkJdkuYb4J9jhdMfmlfvQox2Mbnk2rQ+r6xzy9iAR9bTXWSJAnrkakuhTF3/TGBPU2ZM83e1UguiaLI= 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)(366004)(39860400002)(396003)(346002)(136003)(376002)(230922051799003)(64100799003)(451199024)(186009)(1800799012)(83380400001)(86362001)(31696002)(36756003)(2616005)(6636002)(6666004)(41300700001)(316002)(53546011)(6506007)(6512007)(6486002)(30864003)(36916002)(44832011)(2906002)(478600001)(5660300002)(66556008)(66946007)(66476007)(8676002)(966005)(8936002)(26005)(38100700002)(31686004); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NUxUKzhjYkI0enQ5dGJxL09jZis3TTFJZVpvK3Y1cUdnSTJXR09BTDNzVnNU?= =?utf-8?B?S3JOajQ5cnRsZHVuWGRCWnhUYW8xZjYzK3Frc2cxQmZMRUphcmlzOVNQTGIx?= =?utf-8?B?MmxHUGVBMVhOazlCQUFiREx0YmpJSlZoQlAyNzJ2c1l5NnhrYTZxcGQvMlN0?= =?utf-8?B?QkYzWnlXcGxmTXdyKzdEVlhyUWhzMFFUdkxKWCtJZzRodnBSQnErSFI0VXVv?= =?utf-8?B?bjI2a1cydFppWk9QbEQzZnV5ZWI2Rjk3WC9rUzNrN0o0V0o2bjUwL0FSUTFp?= =?utf-8?B?Qjl6RjRMek1tVVE1cTZWNC9yNjl3VnNsWlkvclNOZWxQMHJGMnI3OUtLSzh0?= =?utf-8?B?QzhxTDUyaE9tSjVaWDAwWUJodnNIRk9HY1IvaUQ5YTVkakNCakJNSE1QUVAz?= =?utf-8?B?L2xjZUYrdFVZaWo1eDRBSzdHL0ZLdDczVFQrV3g0RW9LVTBFdGpUR1NkbEll?= =?utf-8?B?WlZoQ1dXWk44RzQwZkZ0NWNlVlE3MkdXTVpQR3VsZ0dOU1JVV2hwWU5Gbmpi?= =?utf-8?B?NGxPRVRSMVRoNGxzemZBQnAxYW5HNjg5V3lJVUk5VGlNV0M1dUxkL21YN0RP?= =?utf-8?B?RmloUm1vZnl6NzE2NTl5dDlWQ3NtNXV2OVB4ODZvTWJPRTFFbkVuMXJGMHNL?= =?utf-8?B?UlRBNU56RWQ3K2FLRUZGa0o3N056eXFnWDBkWGsxQUZVZGtaVWtpRmZJaEg3?= =?utf-8?B?TmY1UkhSdkdaQUNGZlJDdXJrZTZ5TlpudXBrWWg0U2lkc1U4eUdQMzdJTlBh?= =?utf-8?B?Y0JQVk5TMm5jd1VSZVRTeGtLeTRBQXE3MDJwSE5UY3FyNlNweWhMSmF2anUv?= =?utf-8?B?MjRFZWswbWE3WXpidC8zc081NzMxdlN6VVhWL1JtQnFwcTRPYnRaTDNkeU9G?= =?utf-8?B?YnhDQ3lENTkzUVZ0L1MveSttUVZKbHFiSEo0b0lRSXdSSENMWk9lS0U5UTAy?= =?utf-8?B?STBVZXdPeXJNUTc3TWxMdE45NWxFUDRSK1RCUHppNm1ObmIyZXNOUWdmZHhE?= =?utf-8?B?eU90SW5ObkZWcUpPR2lPNzJ0TVErcDV4bGtNNTlxQWt0Vk1Sb0pOOFA3a3k2?= =?utf-8?B?ZlEwUlc0aWZvTFpleldrdTkwd0tzazZsdS90RXZYV2RjbEtPdWdwblBodk4x?= =?utf-8?B?aDFSUkJ5RnRnMWZCZGNqY28wUVlCRkRNekNXRlpyV1B4cW15ZWI2MHhVbS96?= =?utf-8?B?UW52VTJrUjB4SGpKRUJzdm56Y1l6OGtBM2JCaFZaZDViOXYyUmRMcWxYS0RY?= =?utf-8?B?NFNydURNY3FoeVptZzJqdzZmVFVFUmo4NFh5eUFnZ3dwdlUrOUJIT0xBb09M?= =?utf-8?B?SmkvbUVJcUlQb1F5aDVzRGIzQWI5Y3FYTVhYaGpiRmFkTHNyMzZGMnN1UCtw?= =?utf-8?B?Y2FMLy9uMjQxZWJhUGpnOU5UK3JmNU9wWVRsOFVBMHVmWnF6UjRXaEhqeTJB?= =?utf-8?B?VGN3SE5ZM2JFZnpUMGU2WU5rSEVBUEEvNmlleGRGdTlRTytIZll2RmlqRlFs?= =?utf-8?B?SnAyM1pKRkFPb0drZmJxVHlVZzh4RWdyK2dPMGhtWlFmRFhINm9hYnZVcTBj?= =?utf-8?B?NGUvUlM1S0RhWlVFYlhwVnpVWnRTSzdVenkreHFFMXJ5NHRwYkhaS2N5VVVI?= =?utf-8?B?RXlTa3d2Rml2aVdRWkdjZHkrUk9KeGRiOWQxTVpJa1UyOElWTUsyVmhDTElh?= =?utf-8?B?U1haQTA2RW9Gb1Zwclp4UWczYmNWTTV2ZWJzWC9EMXRNaWlTRk1kWklsVG5S?= =?utf-8?B?YVB3aWwvQXpJRkUwQUxrb3JMZ1NoRTBzS2hzYWFsTG9zaHVZTmh5cE5BaEZw?= =?utf-8?B?UG43Vjc2c1VOdzltam5Ed3I1T2doWWJPTGRkWk5uVFJoZG1WeTdZSVZrN3lj?= =?utf-8?B?ZW1UemY0MlBMNGl5RG9Vc05wUEFodWRjNVBIQXhsMmp2a0N0RUV3NEtYcmJP?= =?utf-8?B?TmlPM0E4b0tOK1J6enljY3hiNk1PblJjbmNBNG9ZU0V6RFVXMTAyaytkeEVt?= =?utf-8?B?UUZocndjaFR4a3NVK3cwS1NRSzdkczlaYy9qcXVIK2tORWFYemROWUlXK1FW?= =?utf-8?B?QmxBcVBoTk5PbHZrU0pCNEVnRGVWVDRkaEF1aTlJRzZ6ekhuVCthTEhLN0oz?= =?utf-8?B?TW40M2oxMjg5dGR6b21wNEQ4a3ltVHI2RGVLeGtoQkFBL2xvc3hSd1NFMU04?= =?utf-8?B?YWc9PQ==?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 4OrBOzkeh1K9uUS786SWJ3SJXPKnxX76+clZCqk1GjS/aJg+ITUjpsLIxttwXgcWwB4XldtwtFPhsl5/zbHkgGgE2N8Fer8zOWFY9l00AGOBpSkBLzhSI+GCCwumSH+v8QnxeVjNQQF9kuRcnBWPYxmuc5RxO5T3TKUP8SnP82qhZ6t7mTyUCBgXzOaunc7rNE9J6gqBqr99wb1cNRwvi6kGX370Q8nZtc76H0dviPOx2IFMJY/3h5igpJDeZYtYAyxrTm110D4jrK3Ey281daAd3m/Tt6Kw0FR9qGrxl7yrsNEziTtRLFTyvjmVckx206PX+0BMP5z3Vtg+YJ2xyXBuZYwzwYDUW2g04vchIyBfxxJqo+J7VUVP9por5g/joXVIY/C8MfXlH2ZK1pRou0+07VYgo01J5vny5hXbke2WsjoaoiZWe57VcLRyCIj0LiD4m9ywASbmp5Ej6zCZ/4YTA+ZTV4cwo+tdVRKiUDGO4MrMHKJ/Yy1CWzsl+N1wmuqJ6WTKsfso2QY0IZPEo0hpX0oB75542EDAmOiWrCngIufx4vquDE6/MLonWN9EubZ4kGOJNlbMc15ceJ6VA/OaoK2QmW/aQFtpWJCUW6A= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: c303e97c-ce3c-43db-a34c-08dc31091768 X-MS-Exchange-CrossTenant-AuthSource: DS7PR10MB4861.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Feb 2024 05:10:30.0400 (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: 4RVlvhQzhdDkGG/eCpmPXmisDel9IFm1nZXykb1VPOds4QopjjGENC2zU5TqosEiU5vtwILvddNaCLjZjzGoZjEd02MiX4M2PKkAVSB9F1Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR10MB5094 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-02-19_02,2024-02-16_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 malwarescore=0 bulkscore=0 adultscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2402190037 X-Proofpoint-GUID: kYu5bbM4YyQmmzDHv76Y7um6rDzr6Odj X-Proofpoint-ORIG-GUID: kYu5bbM4YyQmmzDHv76Y7um6rDzr6Odj X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE 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/24/2024 8:49 PM, Partha Satapathy wrote: > 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 Hi Team, Can you please help with further proceedings on this. Thanks Partha