From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id l1RnJH7pQ2VbRz0AWB0awg (envelope-from ) for ; Thu, 02 Nov 2023 14:25:02 -0400 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-03-30 header.b=HesZ79nn; 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=UMqI7UBn; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 852BD1E11B; Thu, 2 Nov 2023 14:25:02 -0400 (EDT) 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 447701E098 for ; Thu, 2 Nov 2023 14:25:00 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B52A13858409 for ; Thu, 2 Nov 2023 18:24:59 +0000 (GMT) Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by sourceware.org (Postfix) with ESMTPS id 4642A3858D32 for ; Thu, 2 Nov 2023 18:24:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4642A3858D32 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 4642A3858D32 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=1698949488; cv=pass; b=Cl8vBTNspd4gJ347Phj37TMiLjnO1yke5/so5fsbLgHDKRjb7xj9IU/+WpnCX+CE/HEQmN9YSOnLSiHEvh4cgpXXUO6xY1OyQcLOKGEfY97yjeLSpx//UU9fVFD7Jj53TbUr+J7KhA1D24UziFqbKWFnl0xdWmo1Ke8TzudVHsk= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1698949488; c=relaxed/simple; bh=hC4/i7dIsWFs+t92foh0b51p0SBnsLc4pp8ZS9AXE64=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:To:From: MIME-Version; b=mfVxD4hEBWmMx82MvK/5lbciQfw7lQmSNpuknixxu0vZ4KeaZpdNlNiKvC3TdqRI8u0P9K5l11ABJZP/P3N0jLp2b1Q6mbeHYl5aetLVqmX0GLEH7thlcTzEEZh1nOHT0cH4vs41rnOiDseiDuo5ItxKBsOgCHML55piKNhFDW8= ARC-Authentication-Results: i=2; server2.sourceware.org Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3A2FjfsA002645; Thu, 2 Nov 2023 18:24:36 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-03-30; bh=OcVtbisDjuexhH1wxs6cBMDz0XrAEz09YzBT8bn5sJ8=; b=HesZ79nn7WfNnJ/zPe7FB6PfkyZ/Rno5wRaGT7MFxDfzdp601CMe7HjCdudKp7JPwLhg SY0kGOpxaPVH2+TFMTIuHLlTMsXOJT/iKCVJOkh6jMal9J6LqUx3Q2EYI8UtCQifNruP jciCAyCAYAa5M+t7bmCqZYGXBt17Q6zPfIMj78QXL/VchMx2auyLvXwFAaOVGLuyX4S+ EQjJ5obn2wZXyEpH6GPf2WyICWF+TXu0MNCSHYHjFc8tRG8DUrwY9nq8gqdx5ygKeA6b oAdBKyXYDw71HDNVI2evPGbHDVzKPJK76Qk/H7r8LICXsVifMLSUQt0b5fN8pzsbWdBp ag== Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.appoci.oracle.com [147.154.114.232]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3u0swtthuv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 02 Nov 2023 18:24:36 +0000 Received: from pps.filterd (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 3A2H8FAr020068; Thu, 2 Nov 2023 18:24:35 GMT Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2169.outbound.protection.outlook.com [104.47.58.169]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3u0rr918hw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 02 Nov 2023 18:24:34 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JsjjXhvxCI+U0W2fdDWP04w/zWKzNUs5fpNxdP0iaWZ+WNeHWShNLK1d+uiPSEewIjk8YUMQvLdL0SJjpoJTtXuKhC68jatKtbXTyuwH2ZRfGXCZFcyNuwiPhUw7Z4wgdgio4MIuTTSYbvwDHGbR1MdkT3XPLc0mj8L8D2ZkiQJ6zmT7R6/Fw9ZobjA2zFMWEXgdNS9XDZMRyHHf1ZrMKqxAL/ceaYNl5cdYPPQhEzIQw+jn8ExkcayFKclElGNsgPtQgn+UO5JCreBbcYudPC/AGQjpYYLuBU95YfwWsGzlEDWAPvqY05N+X7TnfcJAZYdbrrzuZltL47SdWYZVDQ== 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=OcVtbisDjuexhH1wxs6cBMDz0XrAEz09YzBT8bn5sJ8=; b=kikDYYnxC4h+egVFs1ReRAAeCtAhRncdXd0LQtiOJCkKXjgn4PY2Dq7iWvYfzpU6APt0o/LhOuDNb7sxBx5o5W1XojRfKuLv663qq7auZImWG3WX//RDRu4JykDCF7ZjcCTcafk/B7wYtCvPQ3FniR2KBJ+LtmycrUUPKvbdfcyXU4GJ2xOPZeAnAksmAEtZYcbDJCyA8aV+4HfrkehPhJ/kUnZOqZjNenc4pX1U01GzCiQIXX5TVLKhKRJ9Bk4eioeDyYkDnBReM7jgql8tkONU1xquiItjpLBGKh599kvumAnX7PlxYwH4Zhih2NVfnUETkatcrFtGSXbhIElRIA== 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=OcVtbisDjuexhH1wxs6cBMDz0XrAEz09YzBT8bn5sJ8=; b=UMqI7UBnxgy7tlJpSJeRj2TnvvjvGOS84V9ogAc+kE06DFT16BqTJXgygvtc/EiCbOXRdPiDR2wbISE9tDy8FZlzPKaYLAP1AwmJjsrGBDcLwnzjlpD7wexdHdt1m91icLUs8XOK8rib7XV0lGRaV7zmvjnOSagIqnEJDmSjdxE= Received: from DS7PR10MB4861.namprd10.prod.outlook.com (2603:10b6:5:3a7::15) by IA1PR10MB7513.namprd10.prod.outlook.com (2603:10b6:208:451::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.19; Thu, 2 Nov 2023 18:24:32 +0000 Received: from DS7PR10MB4861.namprd10.prod.outlook.com ([fe80::fad0:e15f:68e:d7a0]) by DS7PR10MB4861.namprd10.prod.outlook.com ([fe80::fad0:e15f:68e:d7a0%5]) with mapi id 15.20.6954.021; Thu, 2 Nov 2023 18:24:32 +0000 Message-ID: Date: Thu, 2 Nov 2023 23:54:25 +0530 User-Agent: Mozilla Thunderbird Subject: Re: [External] : Re: [PATCH] gdb : Signal to pstack/gdb kills the attached process. Content-Language: en-US To: Guinevere Larsen , gdb-patches@sourceware.org, bert.barbe@oracle.com, rajesh.sivaramasubramaniom@oracle.com References: From: Partha Satapathy Organization: Oracle Corporation In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: SI2PR04CA0013.apcprd04.prod.outlook.com (2603:1096:4:197::6) To DS7PR10MB4861.namprd10.prod.outlook.com (2603:10b6:5:3a7::15) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DS7PR10MB4861:EE_|IA1PR10MB7513:EE_ X-MS-Office365-Filtering-Correlation-Id: cadc306a-e188-43bc-e3a4-08dbdbd0f580 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: FojEmPDgVm4k26DO6et42gW8mC0vQQM4t9WsrpkUvUImBylBxMv7zIbJ5uFhvIgw15Ky7KEKCRYtLMr3mH8kZvxpEnRHNrYFy1WSRAxhZgMhdvaT94no5zt2fSundwbnNdWJZ40aQrs8ile4EKuB8+uLeYzzqN8XCbPO+pa4+Lf3JilUnkbliDRMEJ+quKVAN2FWMi0HJKzURFVBIXgBkPswZhvjqZ5qrnlarrcGUSz2cMXoBX9Hq8v3sEIpTGlbGsFb3atXTIbBPMzULq2ViRLLFV9F+9QdA0Mz2+Cq8SCl0bHto1RYJhsXkRjmMEaJKN6G2ICngQcHJ+KNuGToRN+TCkf8qmOadtn5oq/889ZJu936rlJ24TwtHELVuJu0mGEL5pPYIbYxmZpZfQutSLMESuI0on3TwM0gvx/3xl94AQ12iwbtdyJq2q9mRiZjoOUDscF5mgWUUXMY7FwooNyRhtmrumAJZdIXRVUXbO2gEPCVYg245Co/UFLOc1wmmLXYUTFz+6ggGmoiOxJ3iQrHLoRs/xoU5iR/FFZkQhE8FPuCHpfnvfo5UO/mwbbPstUFzqmXnvLp6eV8/MdTuQgUx4+562FrgFwg0UJbYlK43REWkoJ8NjaR2INodeAplsTm1iSSlutGdvsgGBF1JQ== 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)(396003)(376002)(136003)(346002)(366004)(39860400002)(230922051799003)(451199024)(1800799009)(186009)(64100799003)(5660300002)(44832011)(8936002)(2906002)(8676002)(86362001)(31696002)(478600001)(6486002)(6666004)(2616005)(31686004)(41300700001)(36756003)(6506007)(53546011)(36916002)(26005)(6512007)(38100700002)(316002)(66476007)(66556008)(66946007)(6636002)(83380400001)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MVFTUjByNjRmaGsxOENnZTNUYlFUOFJlVlAzaklCUlFlRVVDeFh2VDk2Uzhi?= =?utf-8?B?Qk5WY1ZFT0ZMc3lHR0Qzd1ZLUXVDSU9kNnBMc0haeTlsS3I4Zlpaa2xzTEM0?= =?utf-8?B?MzNMVW51SDR1L2FBelVzRnNLWXhuQ3lxRG9GOVB4emxwQXVjbFhDcVhEOVNE?= =?utf-8?B?dkpsaU9VL3l6V3lYRFlMeFFnMEZIZE5vK1hkMHZHZG1KQUU1d29JeSs1VFQ0?= =?utf-8?B?WGpVM25TZS9zZmtYKzdrRDBvUzEwRmdDSG5ndHdJQ0JoWUEwVjBTc1lSMFBo?= =?utf-8?B?TFhOTmJOdVFrUEpkZVo2QVNkcnNJZ2FrbHZ4b0FOU2s0Z3RPeGxtZGNCYU4v?= =?utf-8?B?Nkt5RTBhc3lUcjFzWDhMeFhCQ0ZpajE5TFlCUzFUb2VnR3hwekw5eDF3VUFH?= =?utf-8?B?VzBWaGVONjNZalN1bC82N2hvSFVoM3lTdjgvM2FPdkI4NmQ5RFlSRzhzLzlS?= =?utf-8?B?OEZOamxYNkJNa0J2YUZiMkFCREdnc3Q3UEN4WEE1TS9EV2grMTZCZW9RdmtW?= =?utf-8?B?K3hwQ1NOa0JnWnlOejNNUGE2TE9TS2trcTgwM2Rlb0d4aFV5Wng4ajNud2VW?= =?utf-8?B?QzF6aDNlSGNOaDZycXl1RkJJZDZ6alRjdHpYU0JKY09UTkEva2wvR0tQNWZH?= =?utf-8?B?Y0FTWkoraUlKNHllWCttdWtQRXRWdm03OTFFUjRlVVE3ZGg4Nlp3eWlHcVRN?= =?utf-8?B?Nmd1WExGM2RHU2FsK3B2SzlMVjlJalZ6Vm5Ta0dFRTFWUkFyNG9DVUhTcmRT?= =?utf-8?B?bEt0cmREY1dHN1dYS3I4czBZdFEzVmVrWUJVazRCZHZzcmhaNWJxb2FvelVG?= =?utf-8?B?SnBiM1M5ejBQNENZZGMvN3EzZ0ZJVGRYdFgwek1iTXp0SmlURmxoQk9Mem5Q?= =?utf-8?B?QitxMzF2VHlvR285bGdHMlJmMy85cWxwNjFBN1IrYmJwZEFTZ2cxS3Q3RXA2?= =?utf-8?B?RnVrK3M5WFlOYmRTQ0xuUVJySytrcDFraHJHU05xejdBaFJ6VVgzRWg4elRD?= =?utf-8?B?YUZWTXFURzA1NDYzNFl1ZWlsSWNhSXI3RmdWdGhmdlFtY044RFNPOHhRd3VH?= =?utf-8?B?QUh1aVFUMytHb3Z3bGxCUmNQbjIyWlRJQmovNmxSb3UzekM4eHkyYmVCWHRq?= =?utf-8?B?a2lPczd1NXlKRGVOdGlhR0Q5cnloVXpYOXM4dDdscXFaNWd3OFB6Z2hjZDVa?= =?utf-8?B?UEZjekh1ZFhRL0NwQ2o0Ujh1bXg1Rkg2Q1hOb2xsNGhFb1VEVWNWejhRM1cw?= =?utf-8?B?S3JEZHBZUlFnZnZ4KzI4TXlYT204eTcvQ1VTRkdpektUNlBJTFU3b1R3MFdt?= =?utf-8?B?NUZaUDlYZXV5aHlJYVQwVzlYdFowamlGNURGajhpQTh1L0RDR1p0cEhwcWVw?= =?utf-8?B?VE0vdU5sZUlVQWFmT240dURYY3VRZldtVmhKOU9neGd6eEFudms2TFdFNXNU?= =?utf-8?B?YThtcGdYOXk2TkVXNXMyRmZXbllNNTI3U3FubWt4ZFVJQnByL0tmYXRqQ1A1?= =?utf-8?B?blE2WVhSblM2eWMxOUNTYXFmTlNVcWZETTVwb1lwRC9DK2ZYQk1LUks2WTRS?= =?utf-8?B?L2xIaDR6d3RJVVVobFBXYzFJajdHeWZKK2gwNEVOYWN4d2wvZkl3MXpOV011?= =?utf-8?B?L2l3Y2N2bVBXWGhrem9DSjNYWHR2UnhCRklXUW5QSjBQd2t4UkpuazZJS3I5?= =?utf-8?B?VXIzTWw1OFJ1emJROFYzTWRYV1hQNDlleGN0VlhWekd4N3VlWUpXeTFxNkZR?= =?utf-8?B?RnZ4L0VXUUU4SlY4MnlVbGVsUS95T28vK1J2bzBTU2k3WEpEWGhTRTlWbGV4?= =?utf-8?B?ZnF6VHhFZzYwSUlSK0Y3MzkxSDdlQlNFZkpTcjV1ZmZOZkR4ckRPeDUyNWpZ?= =?utf-8?B?YnBnZEZUSXFqY1ZUTS9WdmQ1dXRZL2JXaG1kYTZGcDNZTXdhYUtjWWdEQ2Zm?= =?utf-8?B?eER0amQySm9OZE1tbnpnckh4SFdKMWFqdVN0V0VBZ201L2xIZG1kblNXbHN5?= =?utf-8?B?WHp3RU5La3k4UTlzQmRYdzJBckFSK0RyYlY3MnpPZTYwMy91M1JqenVIMmM2?= =?utf-8?B?UXdURFFBdjFsMnAxZVVLMW9FZGpxSnJvVSs1WkhKekRuYnVGb04zaGhRcXlL?= =?utf-8?B?NWo5UjlwRi91aTZvRHI2UGtBTm1ZRVVTdGpqaVZ1Nk5mUWJyVnVoSkxHNTl1?= =?utf-8?B?R3c9PQ==?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: ckD83g8F8RS8UysVcVLH0lE7CC6hYug9tyo3C9HyalllMHXSZN/C9CWEl82nFfXhKeQ1uRG8/Sg/k+E97AQAqMw1z5ituBER82XKI44HgpqlPbWht2lxJ/qMnLmjFj4qzV73XbybVpkg+U4kLqiEwVXYiXupgEGPzlHmzThjB16JmqbMFIE2982BT4NEJ1EWnN2XH/d4W86Z7M8DJpp0V7wYJnebHs3loz/Ni4XvfXTQm+V37o4U0IFs0DOxJnmXPgwrhULfjZR2op0YtOGtLX07sSdLPqDZYSH8yZxPQpY5Et+wI9IjeOzIMrH3+inHCupR6/S+R2JirdNoKzgVghjzUCfN8WFKVvWEMhaklOEO9aWb6CXZ0t9SwCLCTtjqnUKPz4jOW3VZN2yzn9uX8f52eVZFJLXH3WFt5hoffrOLcjJnBEx7iH4ZXzCtE0TUnmRgteLtRnSxHuaPa9DnPwTlaWwAsGXRP0fewLm4VYYRcbQJXPIqA4Whq2KJp49+BzbODvry7Q5EACByk6l7+YR/PzVW/gtnLTsVah5L5M9D5lZjEQG82k9ztbxLFLPjzDaOZReTxpiqb1i77RiIbpFjuo4j4bnTbYPtXEHE2ejbYAs6hOyWoqO339fvKb2qEt3dco9bD1JhGrSxPLwt1yuDc/7RXKrcSqgmPWTsUXZyAfhBgbyyLEa3kyW863ZIUsp9ZOUB9uE4N+BC1lbT6M52CtpAfHWNQ4FDZtRn0W7+VqInU2gj1ARS0+BIzgkrW9awB2DK9y5gxNCfWEyaZQte9Tj2nAwCZ4CfABrBT0g= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: cadc306a-e188-43bc-e3a4-08dbdbd0f580 X-MS-Exchange-CrossTenant-AuthSource: DS7PR10MB4861.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2023 18:24:32.5361 (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: lj05dKDexIb+SrvpR4WR3fK54JumZJElAD5Qg1fm62HUfEnzLT+K0XTqzcmAFHlWDHZ1PYhLheEaB/yCISukmJqzD3iAfJaX96aDwHuQ1xA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR10MB7513 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-11-02_08,2023-11-02_03,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 suspectscore=0 mlxscore=0 spamscore=0 phishscore=0 adultscore=0 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2310240000 definitions=main-2311020150 X-Proofpoint-ORIG-GUID: wUOvgRQup8ZuQDWloT81ObrUUN4McYLr X-Proofpoint-GUID: wUOvgRQup8ZuQDWloT81ObrUUN4McYLr X-Spam-Status: No, score=-13.0 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_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 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