From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 1SLvHwa/nmVyyzcAWB0awg (envelope-from ) for ; Wed, 10 Jan 2024 11:00:06 -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=kNMVtjjv; 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=zJvQpZ9M; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 6E5101E0C2; Wed, 10 Jan 2024 11:00:06 -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 127EE1E092 for ; Wed, 10 Jan 2024 11:00:04 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6E17F3858426 for ; Wed, 10 Jan 2024 16:00:03 +0000 (GMT) Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by sourceware.org (Postfix) with ESMTPS id 18B193858407 for ; Wed, 10 Jan 2024 15:59:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 18B193858407 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 18B193858407 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=1704902374; cv=pass; b=ROJb0rZOS72hAzYOEnx9wh25gdjRATSeAMUqbPU/zG0ES82vwmskzspw4EIpovLXJhdg6NK448qLC1iJEOPgRQ5QLhufXuUzCx0OzREN72SL2/knFVLWSErzxU4Cgr7xh2jXye2RIbAUVXB4w3kQvH6gMciADjBnA8cDwC1zC8s= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1704902374; c=relaxed/simple; bh=9to0VHZXqtHRIKDCQmL3p5FHjgmaYnrnPsLx1HIvd5A=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:To:From: MIME-Version; b=ZLZctbAxzfIMoLOmQfKPC3DFHseSHUylQWZEf85AZ06Zywxd1YabmuaIcTpZrpdbBJVUKi8yqLQul980suzLn5NyFRTSZW5ZZ19kEhvGAAwNLUpZW3QHlcMS5+xl+lN5Fn7pBJ/I+TO1saOi8ZOBfKOlhRHvuqm5QyytTexfDh0= ARC-Authentication-Results: i=2; server2.sourceware.org Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 40AF46ID024057; Wed, 10 Jan 2024 15:59:29 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=message-id : date : subject : to : references : from : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2023-11-20; bh=8yMJ62mIqqz9QlWcH7n3HfkrQP21ALyiQbIQ6su5pJM=; b=kNMVtjjvYVFy/BJlTLIAP3AtDX07J0fhyaFf+2aPJzbVdZLgbpN954Wg9MPp1+tGJXXl P97udF7cgK7eKdntfOACkBiukb3zLsJAMqvpH9WvplkHf0N6kY7wDStZqYI6ULMZOI9e vGvOcXBH+ws6S9rPHr9WOXGpVj8tTfRK5wGh1slzBwZQTfKOj3UJKFTtVEX0ojpgGKcj 8i+xdPHvTXiTCaxgbwwyjtI0bMROUJu3eC8d3DsS920EZroKJ18W6K6nsIHIzoGM7ZXx dB/plQpQ27o3kS+ehNT8rQv1wVqpBFdDqPtNXGb5MqUCg7CFrshImMF5I628JBXnLAa4 ew== Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3vhpg7h2b4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Jan 2024 15:59:29 +0000 Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 40AEcYFC035132; Wed, 10 Jan 2024 15:59:28 GMT Received: from nam02-dm3-obe.outbound.protection.outlook.com (mail-dm3nam02lp2041.outbound.protection.outlook.com [104.47.56.41]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3vfuu69d28-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 10 Jan 2024 15:59:28 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fKY3Fr9o4WFNpkdHBxz9uYw/ZbpKsk39OZoQ1CxEXrBymhzLa3VZFS2FazKDvrWOpKgfdbHza+fU10WusfMIhjYyZh143y0JqPZEb6BRHEnWIBqdlUj8hsiqN5+9NeXwW5KZufYtJU6/SLHJSEclaDprAhHVTMOZxxIf4d5bW4vgiS2runm+KT5lj2aR1hEMb2A1GbHjZedluWIVO8Z4vRS/vMEVh4qoi5dQaqkDGLxqlmIwA/dQnEa+c2iO1O4Mx0Uz1BI3CFKpsuy7Ra8NaTL2c1Pvp+hNAoelF7r4zff9x5o4U/ts9iVEyyTmfROO8MuwoiF7Dd8LFHZ2BDIjEA== 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=8yMJ62mIqqz9QlWcH7n3HfkrQP21ALyiQbIQ6su5pJM=; b=ARpTMm/hJtGc9UHvah3c9TpwyAQIibLaWvgKSbMWx7q0eYHoOP45McMN8C++B2MxY6zdAUShgKFjUSODYW6zHV7pCA7NIT8LXN+yMeQqCAmVKTBdgO/GHzNhu2k+xADQ+isIoOsOL8AZIeWoiwVIRTo3ibwQK89HVzp5lV0C3Oa1dLMIAQwyUPZ+vCN5PQXzzS1vIinRnywdJt9qwQlfSz+VUeCWFYp0e+6cu+wTtHcWdM3hmdM+Uitcb4KTcUvA5KjVUoyvOGNhfzp6uFUva3Pair7MpKIS84/OyFjvLWGz5pMW+VEoFTex9wTSk2pgJ5bbP1E5meGUlKt2wxtjAA== 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=8yMJ62mIqqz9QlWcH7n3HfkrQP21ALyiQbIQ6su5pJM=; b=zJvQpZ9MOjZVXqFqxC+Qrhjfb8lH16x529NODNUyE/UnK8DGKXiHjiZUrKDKcVJ1HFmbvYDpGnoOtmayYCp5/C7Bj6SZaUaXcOKoxjpo2OmgEozA3lAQ9FzFtQ7LB6SmJLcb6GKNgd203WPnrVta3CSmyVlgKhog6J7FC+RnL04= Received: from DS7PR10MB4861.namprd10.prod.outlook.com (2603:10b6:5:3a7::15) by BLAPR10MB4931.namprd10.prod.outlook.com (2603:10b6:208:331::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7181.17; Wed, 10 Jan 2024 15:59:10 +0000 Received: from DS7PR10MB4861.namprd10.prod.outlook.com ([fe80::58f4:c345:fcad:7b48]) by DS7PR10MB4861.namprd10.prod.outlook.com ([fe80::58f4:c345:fcad:7b48%4]) with mapi id 15.20.7159.020; Wed, 10 Jan 2024 15:59:10 +0000 Message-ID: Date: Wed, 10 Jan 2024 21:29:03 +0530 User-Agent: Mozilla Thunderbird Subject: Re: [External] : Re: [PATCH v3] gdb : Signal to pstack/gdb kills the attached process. 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 From: Partha Satapathy Organization: Oracle Corporation In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SI2PR01CA0002.apcprd01.prod.exchangelabs.com (2603:1096:4:191::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_|BLAPR10MB4931:EE_ X-MS-Office365-Filtering-Correlation-Id: d67a74c4-92f5-497d-0f77-08dc11f5157e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: HOJOmrT7pRQL53m5VXaXxvIWD9OVeLrY/SEGwkfbiG55Kq1NBS6eHJ2RanAWr/ZNqQg5+9EowFlCWzHag5d63OvmP+b/BnUGVeMDen3KfPqVz2WmGnVHHvF7m+057Yk8nmHlzcDOMy5Wd6MpnDqF7BCEPMWLwVxGPJsLF1qNl8op6bV4uVpunZPdMg/F0jDyjOL+7zCkd60TlxpunjGqzeFWzV7QIb8yfwyL3K7dC5JPErADS9JwzSlovKhkQKsdjaR/tmrnKPAc58WLhGIqboHtnaUcN7kb+lXh1EkjHZorRCoxKRS+NFZfdiTmVpxmst6UXsyfWZ3MV5/PB2/t3LpoDjmMGaZ054NwAi6c0DHrjy1DxJQmOni0+4oNm5HS9A54qAMUZtZutcqqpesGxfTJzdkY6FSGgzxxy5hA43YYdC/S9DfMxUOOu+Ohp29tyzISl7pIV43c2gUMo7FEc4zg+yRlIKV+eOfpJkJSa3QSsFAWgXDZY7N2t/VxpqoVWu8yK/ju3eCxoENracRlPL3SrIsVEVAt05adXR88AsNmtrH+svQomSIOvmaoSOhS2wU/+kuhxS6hwa9cxQzU/Wmt7r/RbzMxHNH5kgFnFvVdXRqmLeqYueotFf69G4sXL+6hsqs6YPWzVDNIQ+01MQ== 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)(39860400002)(346002)(136003)(396003)(376002)(366004)(230922051799003)(64100799003)(451199024)(186009)(1800799012)(30864003)(2906002)(5660300002)(41300700001)(6486002)(83380400001)(2616005)(26005)(478600001)(53546011)(36916002)(6506007)(6666004)(6512007)(31686004)(86362001)(31696002)(36756003)(6636002)(38100700002)(8936002)(8676002)(66476007)(66946007)(66556008)(44832011)(316002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RHRENjMzb2dMVTJQU1ZHbGMwVGF2cTRqMVdCSzVnalpwUEZLcGlZdjIrVC93?= =?utf-8?B?anN5TGw4M3NKNlFCQyt5SXZ1RVJBeTRHUXY0SHRzWUwvODBsTDBSQmsyY01r?= =?utf-8?B?QkVRNXdvUkRzQkZRQjJEUzJyS0R1Z25Pc1kxRHJsN0U4a3l3MytzcHRjSDh0?= =?utf-8?B?OWh1YzFlYUxlMWNFZDkrRUh2SWtmU0txazArdE9OaDZUSU54ZVoyL2JkTjM5?= =?utf-8?B?ajVHNjlyd2RRZTdYbWxwUkV1ckZiQTBYN0xkdTA4ZFJZMkdHMTd5d1J1Tnls?= =?utf-8?B?eU5CYldxVFhvYVJ5dEJ3SUhZQ0xKMW1XQit0cDVacXQ0cUUzS1VsSWk5czlJ?= =?utf-8?B?eFREQ1hsbnV3RFlCNWxvMEJxdVZNUkNpVCtrODk0RDRDbVU3cEVtTE1sZmE0?= =?utf-8?B?TzN6YXJ3czdMSUwzY1QvV2J5VWNnUElLaXQzUW5ZeUEwNUh5TGs0WUlHdStE?= =?utf-8?B?cVl2bUx0REJ1bERhbENsTmJBUTUrcmJHYmhjWFpQS2FIUlBEZnhDYllGMkla?= =?utf-8?B?YzJIcThFbzZZaWE2MzMzSTd4SDBUK000aG52ZldzQkpLYzlBbzBUYVplTGda?= =?utf-8?B?amVnRnIzM3hIUXNWbEtKTXNmdEVJMElBei9MMk5XRStUemR3V1hhT0gzOXVT?= =?utf-8?B?c3hnNVpQUlZkU1haclhveHVXOENxaGdWSElBaVIvR0psdmJnbjQxUzlGbjc5?= =?utf-8?B?bmJGVE5iN21kREltOWV2aEZXcFE0QXo5VE4rSkp5ZVloalUxYjVwOUVEYWVm?= =?utf-8?B?a2s2b041bDNwcFVMdGN2UmVObnB6aEFLSm1SYjB4WTRvRlJNU1dOeC9zSy8z?= =?utf-8?B?UHNNRVRoMkxLMW55cXJxZExCblJNSGJWYzB5ZURnaGJwYTFOTlk4WlFOOTRZ?= =?utf-8?B?dGYwRXg0SE02cDJldCtKMTF2b2FybHZVbnFFNjRtMElJak9Udjd6SXlKWHlT?= =?utf-8?B?UEFJYi9NQVdvR1E4UGxBOCtEUCtvTTN3aVU3WFZTc2UvemgrR1RqMnAzcWh5?= =?utf-8?B?OUY2SkxDOHoyL3BvRFhubmpWc0lUNGt5aHRvWkQ2clA0TUlzZG5KbXhMNmF4?= =?utf-8?B?YXVMUU1RcUZtMk5FKzdjU0I3Y3dCWTZqdytyYmtEZFMyTEowQ3BwQkhLZnQz?= =?utf-8?B?UjQ1bFBWaC9IQTNXUUhndTY2YmdJQlRBMmdRQWxQTlVvWTBibUJrWmxBMnRZ?= =?utf-8?B?TWhVS3NiQWVoNDhEeVBJTkl0T0Zzb1EyY1ZrMzY2VjJuY1hxU2FwYlN1Y1Q1?= =?utf-8?B?WG9XdHVZT2Robm1wMldEL0oxcDdZQ0VHYVd5RS9oSmlZWVpQaUZxc0ROeHdS?= =?utf-8?B?TXp2UUZKU0FLQk1hOTk5OTVrOG9XdHNkTHFnZDl0aXRYUXRmTWFhWWlmdGdn?= =?utf-8?B?SHplTnVIRHZQN3czRndCRjZ0YmhwcHhpTDZsZzlvdEN4MGw2T0dGODcwbXJo?= =?utf-8?B?MVIrUXFlakw3Nk05RTRCNGduQ3VCOXVpQkFnLzcwRG4ybnJ4UUtNcnZwYU55?= =?utf-8?B?b0tjNFRUaXk2QllYdU5JYkE4UXVLckV6NmJNSGVwRyt0Q0hlQkJJdDFKY2kz?= =?utf-8?B?bEJNWFZZMm14bG0zSU55VzlqN0hGcGtHdzlITDRndUlRMzNaUmU5TG92dVM0?= =?utf-8?B?a1B2aEJIOW4yNVJ3U0xuK2h4aGpBbk01V1BHR1FXeGlTSHVmYmkwSnRJSVJD?= =?utf-8?B?c1NPVCtjaHV3UjdDeit2RFkxNmF3QkZMU2xtdUlJTjkxUVRrbUltU3lpbWxL?= =?utf-8?B?Ylk5Sk1tMmdFN2tVbGFKL3BBK1RPb3pDbDNzcUR5ZFEwUlNnZSt6NXViSHJV?= =?utf-8?B?RTZub0tibVhSVXFZK2dUTXYvWFhCNWkxb2NKLzBESmpPbzFPREVNZktKZ2JG?= =?utf-8?B?eW5PZHN4cnBnaHN3Yjcxb1lENXJRZDNTYkhlWkxnMUc4VUVFSmhFTmF6bDdV?= =?utf-8?B?QjE1NkNjUGZGTGtlVkhtSEpvYktyb1ErRyswRkJ0NzQrRVpmTjZseFZOamxh?= =?utf-8?B?TUhPc3BERlhuTUNDVCtHaDdoU0lqS3g4SW1jQWtPdGdVSU4yMStNVU5mTG1z?= =?utf-8?B?ZExrdXlpYkxCTFVhV29PSE95bWdnSVRXT0p5S3pSaFBtRndhdENjN3ZHVDZQ?= =?utf-8?B?QjhUa0FQTldEd1VPWnpUUkRyVVBrOVFEZi9YL0xZQmdQTGhTZGF2citUYXdD?= =?utf-8?B?REE9PQ==?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: zibXhaKFHPPzSnpnFTLn1GG542RvZyEF7H3TkUiFeDh3+/+1TyTrP4u5c+ubhQfxuXM1xlV0QXrM8ef5qqOEmKfvuyJ+rhYctlI9KXj+Ppmq8HC+puMfob2TqfLNMVq/Y2EAjDTl7OoJTcFYpCXqBN5iS9NzSQuxu2vIU0J4H7XpyBmITju4Qd1zLZ+yeNWf8omBfOowBq4HiPYjrKmHGqaTSKOvnm9K7Jia57YBw1tlVBL4QBgSD4VrDfyQp0gTngk7o86wM3oQGsZdiKY+RlqwHdM/bNLRMtBKXPE+QJZw7b8M/+cMEcmiKBdtty+ejqOGhj3mIxYva7xq8lsCGWR0MjD0taoPRsckOsLgg6pkqVDoGO04odwLun57VZdjKVVi43lhPG1kcvmCLwES2jCzpOaA7r2J6uNtFZgr18NiD3s+g1zZx7doCRXxmRyRJvaC7BND/1MazKk8s3hlc9N7UquMVOfAQ23ZlV/wwCodOuLX3eGchyQL1Xtia2qXpCEedMGE+rcKoYnqFDQMEqW+VhgY/4HCIP76qxUZ+80o7F5IYkgzI+zHUa8pW2xCREtYY4alza/4LLBkiLUxZYzGrA5ni/2wjCbHzgj9gto= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: d67a74c4-92f5-497d-0f77-08dc11f5157e X-MS-Exchange-CrossTenant-AuthSource: DS7PR10MB4861.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2024 15:59:10.8121 (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: wWpXqMxm8tswRGdWpOTSnP6PUGeXHL1Vpsu8RAAbR5hvRzZW2FfyBCVhULDLE/IQqh91yN+hdnrG+RbuY7ircZRoeqYAdwWRVlTtvjjM/Ug= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR10MB4931 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-10_08,2024-01-10_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 bulkscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2401100130 X-Proofpoint-ORIG-GUID: 07a2kPlFavP8Bn4wzzfnAANyI2RWF94_ X-Proofpoint-GUID: 07a2kPlFavP8Bn4wzzfnAANyI2RWF94_ 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_DNSWL_NONE, RCVD_IN_MSPIKE_H5, 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 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