From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 0AFF6385842B for ; Thu, 7 Jul 2022 08:27:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0AFF6385842B Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 2678NGg2031913; Thu, 7 Jul 2022 08:27:35 GMT Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1anam02lp2040.outbound.protection.outlook.com [104.47.57.40]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3h5t0pub0n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Jul 2022 08:27:35 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OcTAmzREd4B0gWFVNh9/7RbeQQRQYQB51OlOEb58LyQxDOFuOcQc6qzCdjSiXwW8JeoZbjEAyeqFiVySK2n5DPa7FRIUnAztPCgQzkpFGwhILcLrELpZ0Hid8lj0qek7Z9zDFhkqJnlBoWk5WVbi/75t//MqCr3A/9ULoAGO/JMKjwUGLjbo5O9xF88MPxR+JMwYv56B8QWhElx+fVwJHCNk2rYB9iHxaoCtu0HzV2ImHgVA+mhMpjqZMbgJOlzcmc2oRJTp1Tz/hOeiKAip5Fwr9oD9Lhwn/RLAkaWSYkqT7+5722BSt8MivpOwrgWhtZ1jRKPU5lJzlZFcQuD09w== 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=eYTPiP29Z01fz440xyQULcwC4cmv8QQ5xxDwQJ6/2H0=; b=e2jQPFFQDUGq2l1JE8aT8HtRuKZxmqsq10j5mFXrGXXqcKg5+oTzPMNamNH0uShIAV9KdGTsxTiRL0Jxvo3gqCJa7dK+57kZou20jY1rLOmkjjOMPKOAtrGPO59uh1AxMWkvmIAFMQLweo0y70lzGW/EI4W/0+hWqTeK3Q5URa30b0h2521qHwDKTq1EG0e2Gntwm8xVVKJ5X+5HgCOnUPzvNnRtrlGkNyMxJe2uEWKVKExzx5Q10dnrx5ING17vvhL2frYMY2hPBuW2IiT+jiKgtoiL6kuTEwaN6A8BCna/hkc0k8H/ejqp6fHkVwexspZMLrk5DkvaH6PKiw8WUw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ibm.com; dmarc=pass action=none header.from=ibm.com; dkim=pass header.d=ibm.com; arc=none Received: from BN8PR15MB2867.namprd15.prod.outlook.com (2603:10b6:408:83::15) by MWHPR15MB1167.namprd15.prod.outlook.com (2603:10b6:320:25::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.19; Thu, 7 Jul 2022 08:27:32 +0000 Received: from BN8PR15MB2867.namprd15.prod.outlook.com ([fe80::bdba:e456:65f2:9f6c]) by BN8PR15MB2867.namprd15.prod.outlook.com ([fe80::bdba:e456:65f2:9f6c%5]) with mapi id 15.20.5417.016; Thu, 7 Jul 2022 08:27:32 +0000 From: Aditya Vidyadhar Kamath To: Simon Marchi , Ulrich Weigand , Joel Brobecker via Gdb-patches CC: Sangamesh Mallayya Thread-Topic: [EXTERNAL] Re: Fw: RE: [PATCH] Fix assert pid != 0 assertion failure in AIX Thread-Index: AQHYkPB5Cp8faEwdEUKGcrDnpjbOEK1xn/8AgADv1Pc= Date: Thu, 7 Jul 2022 08:27:32 +0000 Message-ID: References: <5f142468-bc68-9128-d4d6-80cf36f12a48@polymtl.ca> <87169b93-8be2-5ccd-6b58-51b395a367bd@polymtl.ca> <4516dbf7-2655-39c5-0614-8235df05248e@polymtl.ca> <0ad5c21e-60fa-e52d-f70c-d2bc62e0ac74@polymtl.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: fd27c6c0-0cf6-49ac-cf97-006c8d06e39f x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6aec3308-ecca-4ab1-3eb1-08da5ff289b6 x-ms-traffictypediagnostic: MWHPR15MB1167:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bSO4VnpPsRd/YCr5rZ2wEDYsOE6wNBWRvTQqMqLJUfSWH+IJuCNVmol+g0vDQroFHiPVr3iN5PaFOFBW+EItFWjNsmFZo2CjhGS5sHijyXV69HO6xva8gparBuxQahY8/gCQHCP1iMA7U/dJDMcYZUcWaLub8+cZdJeCqIsbNO+/xWSFzV6XJwJLLrxovhAtZLfaBRA7uznHHscjVvOzn8Q+H1hPMFdxlG8qKSEjerY8KH8RLqQTGw1/pxzQvQaT9RYNgWP1VRtZEOYba306MZsl8gt18MC3EBuigXWubI+P6w3WbNDRH8EqMi/fPt4wmML9cgd9RyWvLkUcGUguxAG9BJQURlvuP71MJzhL/6cGVeiNPJuMjTq9sdp7fWcKy/JqSns6LS0W5Rf3HqBbQEe44LGovnOCNw85meBNzFSxpQOfIkzbyqp63W6bxIy5y4MwLOWgk3RBgOocsQhWwlUxaTqk3nPYwxA/VkXyutjGUllB4MBI4PNpxLDAkUSonNur7wnlFVLI7cxN/CW9t2/mSQqGwzj8Cd1ecCvLmMcAq5Qh1TQEP1z4MXAXTtmJCFsm8Ul75qD+jZeYNvgMtbDurRz/2GwsP17DsbA16R/BNd7znfjz+Nu9/dncdBGkEerTvnbgFGGp8eu5F8W7pAYuIzfAOV3nXb/ohzAKutgICrTqjJsyaO3kvB4pZiYRJUb0wmKgFcqtS5kT41Ed4FEhUxL+U4O0162Di1rx//SPumCB+gheR6MMH78WGLQfCtJK0QT28SJSUjISuiOTcdWjuUo6fN5xRM5/0goZRknBqmCcjFv6ApcLo9twEClEVOSX56jC6AnZ5ug5JUwqVA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR15MB2867.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(396003)(39860400002)(366004)(376002)(346002)(136003)(5660300002)(8936002)(30864003)(52536014)(55016003)(2906002)(83380400001)(38070700005)(33656002)(86362001)(38100700002)(122000001)(166002)(110136005)(478600001)(71200400001)(966005)(76116006)(91956017)(66946007)(4326008)(8676002)(64756008)(66446008)(66476007)(66556008)(316002)(186003)(41300700001)(26005)(9686003)(6506007)(7696005)(53546011)(19627405001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?/Z26yzmABzfVHUszzw24fNyHkjdsoZYXQXpBdF48gO6F5JgHdNPBAbfhmo0w?= =?us-ascii?Q?FH2EVoqttt6aurViyNlDeQJ4iDBzPSZx5fgNPVT7XP6VlyC5r9bgVDC65agY?= =?us-ascii?Q?d+7FOyK4lminvWMO6gZVxS8CNxbQIc60mrKQ/Tt6QmxvcfQBE6Jzf8XlPDbi?= =?us-ascii?Q?Ixe19+kpE8LF21Fzvts4/FT5Dmy4sK11csxYj4sXyWQowsr6+z466RyNfh5o?= =?us-ascii?Q?XRMICOJzl6LRBNQqoexkCgkHnJZgrmt4BlBL9Si8gbH//eJ1LDCa5TaY5sMZ?= =?us-ascii?Q?99PBgsWcisNbI423kAgcPdPtiGhHmOI6QcJWVl1if88HucFvxVK9Ch04jYLk?= =?us-ascii?Q?8/GugNNWolj1c63w0e0A8iv5aec7dr1SiDcUPE9WRxOIcEUBuAENbttvemlU?= =?us-ascii?Q?tcMrpoBk3HYn1Ct2Mcm6ji4oog5gqDP07GW6jYSk5srgAeLwKvb/ZN6aUcvK?= =?us-ascii?Q?TRgRpzu2bKRm3wd4oAiay+Q4ARCeRsvm8tY6EahUZi87pQusaWRu0aB0i0YZ?= =?us-ascii?Q?ZL6pWsfCMgReV5cuc2XVaofCWazAYtmvt+H2Ncv/tP6GRpsLyXqao5puPiRq?= =?us-ascii?Q?ZjGh9gCwqXlfNsyzsVJQnQh8EZdP0xm1IYiD0HQrYodpRb95rvNj+eLUnY4A?= =?us-ascii?Q?Bxyt6fnAzSs5oYt9JJFwmzXIDZmZxnksZkCOmfPnwG8USPFoE773Z4rT2cMA?= =?us-ascii?Q?kXY43Cu0tJXJoQ8suIrRbh/I3nT/pr/NEIN+HjYyyiS1ocu9Lyoo0iYwB0z8?= =?us-ascii?Q?FcHsrLnG7G4sL39AjIAQIsdc13o2MadukZSEF8y/+BEg8dfm0YFEOzuHBSr4?= =?us-ascii?Q?tgYt0f8l3xz1bzSEfLWXZg4VIre4Oizxx+wwqjo6cpAyiuAZ+/dQEwbvTFdT?= =?us-ascii?Q?wOf8LeQ5KN/w9In1ILrKdQXlujlbEyp/QdK4t7C/wXMkcEBroEL7gxDDAkwe?= =?us-ascii?Q?mplkMH58i/3mIvvZGyNZwFOcziUFCFrPseaUOQ140CMyBqSFzXfmxD0fKSNC?= =?us-ascii?Q?ZpYYIYsbCvov5zL/HUJrVKOJdSpNafVZhyeYYL8DatoBRmSKO0jTZiQ8ILF8?= =?us-ascii?Q?PllNQM+E37LW5n4kuslW9qU2e/5xLog3lukYNeUmBtd1yYj27TfnFVR9sSX4?= =?us-ascii?Q?mpw4G66SEOvuvvBULlYYzqy6qZ51vsMwsf15zzgrN1yyLhzF+elYOU7tdtog?= =?us-ascii?Q?E4OAL2CWxemSDQwQeqOGXaogdcVXge8V4Gf3sJE/N3tfWhNgbIgpRK3Wm6Zn?= =?us-ascii?Q?JUOQFgrK7MbV3qXSUv5RiYT4BxBUfCqGcCopCi9de+Hqyaq7CkAhxMKLRA9h?= =?us-ascii?Q?qBuaBpOVElJdhcPD5fEWdxntZ2wdZCahFKTdRrbMGN0zuZNbTRRQgI8ftQzW?= =?us-ascii?Q?/4WsQ3yQVe3tc33ex/VvfKAXn695ShyZyoSF7QYHs8vYUNId8JaQkhZyZlrF?= =?us-ascii?Q?M6kdhni9ui6y/NBY6MKVDYoMQiygrE/Vz9FcUpGvN1FipZDtg9e8D6B/+Rv/?= =?us-ascii?Q?03WsRL40I4iJz+b0w862TgL76Kpk4jRwDFm/BxwnNdqKpLQ7vK69TWCpLcCm?= =?us-ascii?Q?cmBzrowusJenXedhVIxzbi3kQ18/97wzar9FOLnGlOjCM8ACUTHcmU+ix37c?= =?us-ascii?Q?7Q=3D=3D?= X-OriginatorOrg: ibm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN8PR15MB2867.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6aec3308-ecca-4ab1-3eb1-08da5ff289b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2022 08:27:32.2868 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcf67057-50c9-4ad4-98f3-ffca64add9e9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PW+jy98BqXIL8WoeZHrHrXMhCel+pNEkMUYh7c04y3shUIYz/YlWLKXg/Hwv0hx9xE53Uk4XOol7M20xh/dbjefD5okvPwEnRXM7z9je7l0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1167 X-Proofpoint-GUID: h93kKD-590YH_s_XLIBV09-NotzWUru3 X-Proofpoint-ORIG-GUID: h93kKD-590YH_s_XLIBV09-NotzWUru3 X-Proofpoint-UnRewURL: 4 URL's were un-rewritten MIME-Version: 1.0 Subject: RE: Fw: RE: [PATCH] Fix assert pid != 0 assertion failure in AIX X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-07-07_06,2022-06-28_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 spamscore=0 bulkscore=0 adultscore=0 priorityscore=1501 clxscore=1015 suspectscore=0 phishscore=0 mlxlogscore=999 malwarescore=0 impostorscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207070031 X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, HTML_MESSAGE, KAM_LOTSOFHASH, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2022 08:27:43 -0000 Hi Simon, I appreciate your patience to read our explanations, understand and suggest= us the right path. I was not aware of minus_one_ptid. I thought since pid will be -1, if a chi= ld process in not fetched to send ptid_t(pid).. That change you made looks = good. Thank you for your guidance for someone new in this project. Changing all function parameters will help us in our fork patch coming soon= . So that change also looks to good to eliminate depending on inferior_ptid. Multi thread programs are not seen even from my end. Yes, there is some wor= k for multi thread case. Will work on it finding out a possible solution so= metime next week. Having said that, we can push the changes so that folks using AIX will not = see the assertion failure for simple programs soon. It will be great if it = can be done. Have a great day ahead, Thanks and regards, Aditya. ________________________________ From: Simon Marchi Sent: Wednesday, July 6, 2022 11:20 PM To: Aditya Vidyadhar Kamath ; Ulrich Weiga= nd ; Joel Brobecker via Gdb-patches Cc: Sangamesh Mallayya Subject: [EXTERNAL] Re: Fw: RE: [PATCH] Fix assert pid !=3D 0 assertion fai= lure in AIX On 7/6/22 00:25, Aditya Vidyadhar Kamath wrote: > > Morning Simon. > > The reason we were adding one more inferior_ptid!=3D 0 , condition is the= previous condition in the and logic i.e. pid !=3D inferior_ptd.pid() will = satisfy as -1 is not equal to 0. [inferior_ptid is set to null before comin= g into wait]. So, in the next iteration since the process has exited waitpi= d (), will lead to ERRCHILD error though the current iteration fetched the = right pid using waitpid (). > > However, we get your point that inferior_ptid should not be used initiall= y [for any condition check till we fetch the pid using waitpid ()] as it is= being reset. > > Please find attached our modified patch where we do a check of the inferi= or being in the list. I hope this solution matches to what you suggested. > > [See 0001-Fix-gdb_assert-pid-0-assertion-failure-in-AIX.patch file attach= ed to this email] > > Have a great day. > > Thanks and regards, > Aditya. > > From a1c5ab5338a5d46eab675a85c28a9b00256d395a Mon Sep 17 00:00:00 2001 > From: "aditya@ibm" > Date: Tue, 5 Jul 2022 23:05:18 -0500 > Subject: [PATCH] Fix gdb_assert (pid !=3D 0); assertion failure in AIX > > --- > gdb/aix-thread.c | 2 ++ > gdb/rs6000-aix-nat.c | 4 ++-- > 2 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/gdb/aix-thread.c b/gdb/aix-thread.c > index ecd8200b692..e5c287a3fad 100644 > --- a/gdb/aix-thread.c > +++ b/gdb/aix-thread.c > @@ -1091,6 +1091,8 @@ aix_thread_target::wait (ptid_t ptid, struct target= _waitstatus *status, > if (ptid.pid () =3D=3D -1) > return ptid_t (-1); > > + inferior_ptid =3D ptid; I get why you are doing this, because the other functions (pd_update and friends) then use it. However, it would be nicer to just change them all to not use inferior_ptid, but take whatever information is needed through parameters. See below. > + > /* Check whether libpthdebug might be ready to be initialized. */ > if (!pd_active && status->kind () =3D=3D TARGET_WAITKIND_STOPPED > && status->sig () =3D=3D GDB_SIGNAL_TRAP) > diff --git a/gdb/rs6000-aix-nat.c b/gdb/rs6000-aix-nat.c > index 8563aea313a..24071a3742f 100644 > --- a/gdb/rs6000-aix-nat.c > +++ b/gdb/rs6000-aix-nat.c > @@ -525,11 +525,11 @@ rs6000_nat_target::wait (ptid_t ptid, struct target= _waitstatus *ourstatus, > > /* Claim it exited with unknown signal. */ > ourstatus->set_signalled (GDB_SIGNAL_UNKNOWN); > - return inferior_ptid; > + return ptid_t(pid); This is not right, as we return a "signalled" event with a minus_one_ptid (pid is -1 here). This is unexpected to the core of GDB, because a "signalled" event means that some inferior has received a fatal signal. So the returned ptid should say which inferior received the signal. The code in rs6000_nat_target::wait appears to have been copied from inf_ptrace_target::wait (the base class of rs6000_nat_target). In inf_ptrace_target::wait, that snippet has been changed to return an "ignore" status in that case, so I suppose we should to that here. The change in inf_ptrace_target::wait was done here: https://gitlab.com/gnutools/binutils-gdb/-/commit/85e8c48c73a5c39a6980f9b= 2bd16ec96062fc4c3 See my patch below. > } > > /* Ignore terminated detached child processes. */ > - if (!WIFSTOPPED (status) && pid !=3D inferior_ptid.pid ()) > + if (!WIFSTOPPED (status) && find_inferior_pid(this,pid) =3D=3D NUL= L) I think this is correct. Just make sure to add spaces where appropriate. And we prefer nullptr over NULL for new code. See my patch below. I managed to build GDB on gcc119, on the GCC compile farm and wrote the patch below that at least fix things enough to be able to debug a simple program. I tried a multi-threaded program, and while gdb did not crash, I was not able to see the multiple threads, so there's more work to do. But at least, this should be a good starting point. Please let me know what you think. Simon >From e9e35416a45a8454dc87cabf9462e6cf4040d088 Mon Sep 17 00:00:00 2001 From: Simon Marchi Date: Wed, 6 Jul 2022 13:39:22 -0400 Subject: [PATCH] gdb: fix {rs6000_nat_target,aix_thread_target}::wait to not use inferior_ptid Trying to run a simple program (empty main) on AIX, I get: (gdb) run Starting program: /scratch/simark/build/gdb/a.out Child process unexpectedly missing: There are no child processes.. ../../src/binutils-gdb/gdb/inferior.c:304: internal-error: find_inferio= r_pid: Assertion `pid !=3D 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- 0x10ef12a8 gdb_internal_backtrace_1() ../../src/binutils-gdb/gdb/bt-utils.c:122 0x10ef1470 gdb_internal_backtrace() ../../src/binutils-gdb/gdb/bt-utils.c:168 0x1004d368 internal_vproblem(internal_problem*, char const*, int, char = const*, char*) ../../src/binutils-gdb/gdb/utils.c:396 0x1004d8a8 internal_verror(char const*, int, char const*, char*) ../../src/binutils-gdb/gdb/utils.c:476 0x1004c424 internal_error(char const*, int, char const*, ...) ../../src/binutils-gdb/gdbsupport/errors.cc:55 0x102ab344 find_inferior_pid(process_stratum_target*, int) ../../src/binutils-gdb/gdb/inferior.c:304 0x102ab4a4 find_inferior_ptid(process_stratum_target*, ptid_t) ../../src/binutils-gdb/gdb/inferior.c:318 0x1061bae8 find_thread_ptid(process_stratum_target*, ptid_t) ../../src/binutils-gdb/gdb/thread.c:519 0x10319e98 handle_inferior_event(execution_control_state*) ../../src/binutils-gdb/gdb/infrun.c:5532 0x10315544 fetch_inferior_event() ../../src/binutils-gdb/gdb/infrun.c:4221 0x10952e34 inferior_event_handler(inferior_event_type) ../../src/binutils-gdb/gdb/inf-loop.c:41 0x1032640c infrun_async_inferior_event_handler(void*) ../../src/binutils-gdb/gdb/infrun.c:9548 0x10673188 check_async_event_handlers() ../../src/binutils-gdb/gdb/async-event.c:335 0x1066fce4 gdb_do_one_event() ../../src/binutils-gdb/gdbsupport/event-loop.cc:214 0x10001a94 start_event_loop() ../../src/binutils-gdb/gdb/main.c:411 0x10001ca0 captured_command_loop() ../../src/binutils-gdb/gdb/main.c:471 0x10003d74 captured_main(void*) ../../src/binutils-gdb/gdb/main.c:1329 0x10003e48 gdb_main(captured_main_args*) ../../src/binutils-gdb/gdb/main.c:1344 0x10000744 main ../../src/binutils-gdb/gdb/gdb.c:32 --------------------- ../../src/binutils-gdb/gdb/inferior.c:304: internal-error: find_inferio= r_pid: Assertion `pid !=3D 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) This is due to some bit-rot in the AIX port, still relying on the entry value of inferior_ptid in the wait methods. Problem #1 is in rs6000_nat_target::wait, here: /* Ignore terminated detached child processes. */ if (!WIFSTOPPED (status) && pid !=3D inferior_ptid.pid ()) pid =3D -1; At this point, waitpid has returned an "exited" status for some pid, so pid is non-zero. Since inferior_ptid is set to null_ptid on entry, the pid returned by wait is not equal to `inferior_ptid.pid ()`, so we reset pid to -1 and go to waiting again. Since there are not more children to wait for, waitpid then returns -1 so we get here: if (pid =3D=3D -1) { gdb_printf (gdb_stderr, _("Child process unexpectedly missing: %s.\n"), safe_strerror (save_errno)); /* Claim it exited with unknown signal. */ ourstatus->set_signalled (GDB_SIGNAL_UNKNOWN); return inferior_ptid; } We therefore return a "signalled" status with a null_ptid (again, inferior_ptid is null_ptid). This confuses infrun, because if the target returns a "signalled" status, it should be coupled with a ptid for an inferior that exists. So, the first step is to fix the snippets above to not use inferior_ptid. In the first snippet, use find_inferior_pid to see if we know the event process. If there is no inferior with that pid, we assume it's a detached child process to we ignore the event. That should be enough to fix the problem, because it should make it so we won't go into the second snippet. But still, fix the second snippet to return an "ignore" status. This is copied from inf_ptrace_target::wait, which is where rs6000_nat_target::wait appears to be copied from in the first place. These changes, are not sufficient, as the aix_thread_target, which sits on top of rs6000_nat_target, also relies on inferior_ptid. aix_thread_target::wait, by calling pd_update, assumes that rs6000_nat_target has set inferior_ptid to the appropriate value (the ptid of the event thread), but that's not the case. pd_update returns inferior_ptid - null_ptid - and therefore aix_thread_target::wait returns null_ptid too, and we still hit the assert shown above. Fix this by changing pd_activate, pd_update, sync_threadlists and get_signaled_thread to all avoid using inferior_ptid. Instead, they accept as a parameter the pid of the process we are working on. With this patch, I am able to run the program to completion: (gdb) r Starting program: /scratch/simark/build/gdb/a.out [Inferior 1 (process 11010794) exited normally] As well as break on main: (gdb) b main Breakpoint 1 at 0x1000036c (gdb) r Starting program: /scratch/simark/build/gdb/a.out Breakpoint 1, 0x1000036c in main () (gdb) c Continuing. [Inferior 1 (process 26083688) exited normally] Change-Id: I7c2613bbefe487d75fa1a0c0994423471d961ee9 --- gdb/aix-thread.c | 59 +++++++++++++++++++++----------------------- gdb/rs6000-aix-nat.c | 7 +++--- 2 files changed, 31 insertions(+), 35 deletions(-) diff --git a/gdb/aix-thread.c b/gdb/aix-thread.c index ecd8200b6928..d47f5132592a 100644 --- a/gdb/aix-thread.c +++ b/gdb/aix-thread.c @@ -701,14 +701,14 @@ gcmp (const void *t1v, const void *t2v) Return 0 if none found. */ static pthdb_tid_t -get_signaled_thread (void) +get_signaled_thread (int pid) { struct thrdsinfo64 thrinf; tid_t ktid =3D 0; while (1) { - if (getthrds (inferior_ptid.pid (), &thrinf, + if (getthrds (pid, &thrinf, sizeof (thrinf), &ktid, 1) !=3D 1) break; @@ -734,9 +734,9 @@ get_signaled_thread (void) have difficulty with certain call patterns */ static void -sync_threadlists (void) +sync_threadlists (int pid) { - int cmd, status, infpid; + int cmd, status; int pcount, psize, pi, gcount, gi; struct pd_thread *pbuf; struct thread_info **gbuf, **g, *thread; @@ -790,8 +790,6 @@ sync_threadlists (void) qsort (gbuf, gcount, sizeof *gbuf, gcmp); /* Apply differences between the two arrays to GDB's thread list. */ - - infpid =3D inferior_ptid.pid (); for (pi =3D gi =3D 0; pi < pcount || gi < gcount;) { if (pi =3D=3D pcount) @@ -808,7 +806,7 @@ sync_threadlists (void) process_stratum_target *proc_target =3D current_inferior ()->process_target (); thread =3D add_thread_with_info (proc_target, - ptid_t (infpid, 0, pbuf[pi].pthid), + ptid_t (pid, 0, pbuf[pi].pthid), priv); pi++; @@ -818,7 +816,7 @@ sync_threadlists (void) ptid_t pptid, gptid; int cmp_result; - pptid =3D ptid_t (infpid, 0, pbuf[pi].pthid); + pptid =3D ptid_t (pid, 0, pbuf[pi].pthid); gptid =3D gbuf[gi]->ptid; pdtid =3D pbuf[pi].pdtid; tid =3D pbuf[pi].tid; @@ -872,10 +870,11 @@ iter_tid (struct thread_info *thread, void *tidp) /* Synchronize libpthdebug's state with the inferior and with GDB, generate a composite process/thread for the current thread, - set inferior_ptid to if SET_INFPID, and return . */ + Return the ptid of the event thread if one can be found, else + return a pid-only ptid with PID. */ static ptid_t -pd_update (int set_infpid) +pd_update (int pid) { int status; ptid_t ptid; @@ -883,36 +882,33 @@ pd_update (int set_infpid) struct thread_info *thread =3D NULL; if (!pd_active) - return inferior_ptid; + return ptid_t (pid); status =3D pthdb_session_update (pd_session); if (status !=3D PTHDB_SUCCESS) - return inferior_ptid; + return ptid_t (pid); - sync_threadlists (); + sync_threadlists (pid); /* Define "current thread" as one that just received a trap signal. */ - tid =3D get_signaled_thread (); + tid =3D get_signaled_thread (pid); if (tid !=3D 0) thread =3D iterate_over_threads (iter_tid, &tid); if (!thread) - ptid =3D inferior_ptid; + ptid =3D ptid_t (pid); else - { - ptid =3D thread->ptid; - if (set_infpid) - switch_to_thread (thread); - } + ptid =3D thread->ptid; + return ptid; } /* Try to start debugging threads in the current process. - If successful and SET_INFPID, set inferior_ptid to reflect the - current thread. */ + If successful and there exists and we can find an event thread, return = a ptid + for that thread. Otherwise, return a ptid-only ptid using PID. */ static ptid_t -pd_activate (int set_infpid) +pd_activate (int pid) { int status; @@ -921,10 +917,10 @@ pd_activate (int set_infpid) &pd_session); if (status !=3D PTHDB_SUCCESS) { - return inferior_ptid; + return ptid_t (pid); } pd_active =3D 1; - return pd_update (set_infpid); + return pd_update (pid); } /* Undo the effects of pd_activate(). */ @@ -1080,17 +1076,18 @@ aix_thread_target::wait (ptid_t ptid, struct target= _waitstatus *status, target_wait_flags options) { { - scoped_restore save_inferior_ptid =3D make_scoped_restore (&inferior_p= tid); - pid_to_prc (&ptid); - inferior_ptid =3D ptid_t (inferior_ptid.pid ()); ptid =3D beneath ()->wait (ptid, status, options); } if (ptid.pid () =3D=3D -1) return ptid_t (-1); + /* The target beneath does not deal with threads, so it should only retu= rn + pid-only ptids. */ + gdb_assert (ptid.is_pid ()); + /* Check whether libpthdebug might be ready to be initialized. */ if (!pd_active && status->kind () =3D=3D TARGET_WAITKIND_STOPPED && status->sig () =3D=3D GDB_SIGNAL_TRAP) @@ -1102,10 +1099,10 @@ aix_thread_target::wait (ptid_t ptid, struct target= _waitstatus *status, if (regcache_read_pc (regcache) - gdbarch_decr_pc_after_break (gdbarch) =3D=3D pd_brk_addr) - return pd_activate (0); + return pd_activate (ptid.pid ()); } - return pd_update (0); + return pd_update (ptid.pid ()); } /* Record that the 64-bit general-purpose registers contain VALS. */ @@ -1765,7 +1762,7 @@ aix_thread_target::pid_to_str (ptid_t ptid) if (!PD_TID (ptid)) return beneath ()->pid_to_str (ptid); - return string_printf (_("Thread %ld"), ptid.tid ()); + return string_printf (_("Thread %s"), pulongest (ptid.tid ())); } /* Return a printable representation of extra information about diff --git a/gdb/rs6000-aix-nat.c b/gdb/rs6000-aix-nat.c index 8563aea313a2..f604f7d503e9 100644 --- a/gdb/rs6000-aix-nat.c +++ b/gdb/rs6000-aix-nat.c @@ -523,13 +523,12 @@ rs6000_nat_target::wait (ptid_t ptid, struct target_w= aitstatus *ourstatus, _("Child process unexpectedly missing: %s.\n"), safe_strerror (save_errno)); - /* Claim it exited with unknown signal. */ - ourstatus->set_signalled (GDB_SIGNAL_UNKNOWN); - return inferior_ptid; + ourstatus->set_ignore (); + return minus_one_ptid; } /* Ignore terminated detached child processes. */ - if (!WIFSTOPPED (status) && pid !=3D inferior_ptid.pid ()) + if (!WIFSTOPPED (status) && find_inferior_pid (this, pid) =3D=3D nul= lptr) pid =3D -1; } while (pid =3D=3D -1); -- 2.36.1