From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id IF77MKcM6GJXmB4AWB0awg (envelope-from ) for ; Mon, 01 Aug 2022 13:25:59 -0400 Received: by simark.ca (Postfix, from userid 112) id C3FAD1EA05; Mon, 1 Aug 2022 13:25:59 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=lcAzCP91; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from 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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id D32031E9ED for ; Mon, 1 Aug 2022 13:25:58 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 567753858034 for ; Mon, 1 Aug 2022 17:25:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 567753858034 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1659374757; bh=ThYBv9RXgPG90xl1y5dBmlXKn3CgLRPTYqP74eJ/g90=; h=To:Date:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=lcAzCP91RAndnHyxnUlrNr9UfflmLqsIzNGNWoD7rP+2gYBDnRhdyvy59nST/iBgi pZMR6qvkdxJbi69Ru2DEMy4QHZrm8uydyC7BKtwhvLDZ3vlkB2LNm/hsDmdQaU9E0z oN4jM4E7nIr02aj2u+vvXE2whLDxB2BVvbDdOYYw= Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id A3BA838582A5 for ; Mon, 1 Aug 2022 17:25:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A3BA838582A5 Received: from pps.filterd (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 271H07xg009352; Mon, 1 Aug 2022 17:25:26 GMT Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2172.outbound.protection.outlook.com [104.47.56.172]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hpjumrp0k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 Aug 2022 17:25:26 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iuUXJBTKe4Zfuo/t4R4MjakM+t40Ekg4RP243eh1a9bPRSkX3vXeAqeaaeUnwAnGEXH2y5EGQ6UZI2RrOrXlzWyE+lVywSHOfwiUr1AViymiu5H//J3HLMq7PFxmlyeYGAYbfEC1bJmIpf9pw/LPNkAZ6Baz7eozO9VtT4AkRJYxSRehsHx2AH3zSAK/EXYg3dHcEhqTfug2D1X43Y7xeM9/b4VFInHZJkLjZl8ptS6d+JHM/8QmQRPcj436UsHwRT2JfJNM6OZ6zR3co08lza3DJ1e5N2LwGmRCj2GugB8RjytAXsPsyKMeRXuOif5/PIcQ5O0FjyrFF4edJ/mBng== 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=622sapZsUqyNLm68WCFlzHGTTJO81XAmfzkPb/y5oZg=; b=ZxrbecIbcmqfpLejRsMFkxA1xn4R1upz5SBgw3fD9O8yoAAyMfZm8PYxAe+twhsDtrt5nqMicNTC4yh6epnKiSB50JRNovF2p+GJWzujjt24BUJuDdDdVQl42KUNYphZY9WrckUV2rMaTRnI5fFE2C9eCntx/Za1sdlUPza3KkNcNEFAPFcZYXRJw5uk/+bPInIZfKExqVuwDHIAeSMk1JZw4eKzSGpcCWqdq/CeJLKb/2SWQ1g2owGLXFgPU1M01CTLcR3bfdD51ZoZMgqA4viFatjPj2YFtUHtzL5doYvEu9xmZp0uLDziQtm0lpwdO4rK+jR7UOpHSZXeMwOv/A== 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 CH2PR15MB3544.namprd15.prod.outlook.com (2603:10b6:610:5::26) by SJ0PR15MB4584.namprd15.prod.outlook.com (2603:10b6:a03:37a::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5482.16; Mon, 1 Aug 2022 17:25:24 +0000 Received: from CH2PR15MB3544.namprd15.prod.outlook.com ([fe80::659c:4276:d40e:7bf]) by CH2PR15MB3544.namprd15.prod.outlook.com ([fe80::659c:4276:d40e:7bf%5]) with mapi id 15.20.5482.015; Mon, 1 Aug 2022 17:25:24 +0000 To: Simon Marchi , Ulrich Weigand , Sangamesh Mallayya , "simon.marchi@efficios.com" , "gdb-patches@sourceware.org" , Aditya Kamath1 Thread-Topic: [EXTERNAL] RE: [PATCH] Fix-for-multiple-thread-detection-in-AIX.patch Thread-Index: AQHYmFFabt4MyRx2wU+p6E9CkzDq6q2AXteTgAVEloCABQVYVIAEWHe7gAAQRwCAADTTAIAF1nNogAVJnYI= Date: Mon, 1 Aug 2022 17:25:24 +0000 Message-ID: References: <49119016e80e58fafea0248887148aca3d1aef8c.camel@de.ibm.com> <841f0915-13a8-bbb3-07e6-54b5ff4293f1@simark.ca> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6b11f426-919c-4385-acc4-08da73e2d185 x-ms-traffictypediagnostic: SJ0PR15MB4584:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NyJzzbTOJ6Kcxw1xq7H50Cs3qYINi+K56C7WYeakIroDRCqWTx9/vZGsyRHbyRQRVn5jbzokAodsc3gimMX4rI6ATFZw6xxwntBGsUsx3jEzcL9E+tE8VwfoLxszoDiRWz67xH+Rs9cE53T78zmiPooirPWYXxYeJnmBcRt9d8pK27L6kFua/gLYOgIIEnrtuRT2fKO+kTgtvpiX64AmfwLwyTsxhk1GYo8ns7EqlrTD/0EXS0tm8Ibj9sJAGu/Lb4dM5LRUflrgobh3qOQt4gi3vHwV1wGyJdULe7TrdW+0ekn7pnFHunYNl2k9YaKKffaoLbeqTeIe9JFDUqly4eYKMRAVr4Ee4CUgDrPvOsNnalJ685n//yo9FaWkh2ygB+P38mAfl7CxViiS+jwcxo9wxVsYmf959A9gGUEWr7FA4DwtE3i/jydBNOlxyPfG+jH3Avwthj0ssuXoSjSD/JDmYTe9E2cAK52mMN708G2PpMuLZ1HxXe0xPj+pd2CxuyO9Ft5bi2ItyKyVdSq7l6okvS9/dMr/oPpTRNImJ4Xc051QWdI7fG0RQ68OOqh5CYloXCGk70ulQx3anCmGl8WRZcm2C6xXGkRe+nEzUnciCJ3/Yn8OTmn9YdXWOxp9/U3TwQB6WwUzpJQHJdlEGx3mBuBbvpi/LjkZoH27RwA8MM8w8nyK5TxMlJ0813uZ5UnGFKvTRdv15hS8bydc9njFmetn7pS3G+AOCmjmE7EilKgUL/IX3vON2WokJR2HJgIJBT226ZjZyM0vBZVvAiVyKzMxx+EHwyKMO55WDN8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR15MB3544.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(39860400002)(136003)(376002)(396003)(346002)(366004)(86362001)(6506007)(7696005)(38070700005)(9686003)(53546011)(186003)(33656002)(83380400001)(26005)(2906002)(41300700001)(316002)(91956017)(38100700002)(110136005)(478600001)(52536014)(8936002)(55016003)(122000001)(64756008)(66556008)(5660300002)(76116006)(66446008)(66476007)(19627405001)(71200400001)(8676002)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?b5yKFlP+Hd3hd7b6J5dbBXGWm3Ji8XQjAzeRmdH0u9cS47Dmi+x1VLEhsU3k?= =?us-ascii?Q?SXN72GO6WT5aO8GteNFR93aVU5afY4viTy44yC3uFF0us6P62rY5JNAmsgGt?= =?us-ascii?Q?XWnJNqEWlYzdR08crhazkITU+2GHg6kybOdFmGZVC8XGIigtYVqVd6JQCyQr?= =?us-ascii?Q?z3anZQMDCYz/YGSgHtRw48hDaCSB5BtvRQ0AIG5aN9CECxmfQcwhytF/hceT?= =?us-ascii?Q?qcu14DaBCmW4uKOasAHbQfe738swpf/K0Vh2XhqcFpIA0RgD1WSUcZuPOL/K?= =?us-ascii?Q?euyCgC2VDmDR6gpMY2T2EbF8owglv8SYNpSy4puqHI3waX7RQryb18xzPlii?= =?us-ascii?Q?vaS4E6EV99sAwfhE4PhzJafd9dORPYKMcRF2WPBpK4wJsWAgpdy+v5pV/IQ0?= =?us-ascii?Q?VX5JBVp4TwmZqElumF1KB6OjNG5Sn8M77GXmQBu/rQiwmHhurAINbB+MpnQf?= =?us-ascii?Q?x3hJJyRIQLA3/FkgahC2BPhmiQ24/8HIcGwKIrDRwaWeopnzrhy5xzyZkGLN?= =?us-ascii?Q?//9UW1Ntl7p4v2vpVBcFdSiv7mWaUhlEXgSv3rQZV6O7hl/Bci/fnCYg+KsI?= =?us-ascii?Q?AWbQ4bxhkZm3h3IpD9l8zhxT5JtWh4q+5D7eV1k/qc4PTk9VtwRXJO3VoY22?= =?us-ascii?Q?WtsJFfU5kT+cGD/0DMyRFSmyMhsZF/4+3trWtmNQyI5U3e8jfn/IcCoteeyc?= =?us-ascii?Q?eMG59LDOJnf/xLgeYFdDNkuTDk3jqgfnY2LTlRGZqXsL9XflpsQLC91VAf96?= =?us-ascii?Q?u9S/E2Wh0Zc6sHggSxTnuYiVwvqrCUGsde/xeYRqgWQKRmIWFOZq1mlqifW3?= =?us-ascii?Q?Q2m0FzrIVfDhkI5+lkMiTTOP2dFELDO1dl7ERoreZxvtwPf8UJnVWSYdSG5C?= =?us-ascii?Q?y7geJa3QxOYMOa2aH26l2kgoeO23CB1T4SLYVUfW+ZfaRH5hkACoMU0TvGWv?= =?us-ascii?Q?XaKI/6+6zwaWFhYXYkcky2FyYaPeLQFSFbIw7HGh8B5MScmdNED+MRCQXkBv?= =?us-ascii?Q?K3o2Xdmmbo6MM44g3aKVhvUYepS4d2heuCn6uHGIIbEMlAKKOlWRlsRAPgsp?= =?us-ascii?Q?dH8WlDQOiLvbPpIDPPy47SHuGRZxt5SyooGvNcY7Dmsuviqh2aq9NnQED4UU?= =?us-ascii?Q?SfvdeK1X7lUdhMdJtw7Jhb8pv9tsyaH5+lF0EfZiO9yAywQ4j5pfDtkIcyO9?= =?us-ascii?Q?SHnme/cAktJv+BrikBTWL1Qf1a1x0pMOJet0FVq/SvGRct1WBpq1w/adEqhl?= =?us-ascii?Q?1WQWzToQ5h6D6dYxQRmVlt75Q+g0RluA5IvpNva+o5NnbRweD3ag2nVQq/hb?= =?us-ascii?Q?j18vwLuzwyy6pjKbyiV1PM6NNLYmsHY82TW69UMzJZgz/AhfH75dh258KVw+?= =?us-ascii?Q?FF5VYuVgJcbpb42hiAc7OGHCIsaKh0U3i5/DGO/NUFClTWgEauWEZqvrLoqR?= =?us-ascii?Q?ml/ZN5kkdKFw0NGmPFAGWiekdg4ZP1MtqQVjmW4Cvw0EyAHsQEGKJX6Z6FTO?= =?us-ascii?Q?2ZOTZcCFlZkNql1j3Si5eIMnXkUaBuEdjMWUN+Fy3w99PcDeXHtx6jIWCQhN?= =?us-ascii?Q?1uZpckyEpOOld7rbcbpijD2AJFbdRnubSqSpwSMZ?= MIME-Version: 1.0 X-OriginatorOrg: ibm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR15MB3544.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6b11f426-919c-4385-acc4-08da73e2d185 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2022 17:25:24.0879 (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: +xTqHPiv9QDv9ue8e3bgeRn8jfxaRN4+LGIz0paIMypsRlKcuFt75pQ9hbjXrNR+L19iJrFvXhG0xTwZkNjlgQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR15MB4584 X-Proofpoint-ORIG-GUID: 2Mi9oE77b3pVryyDgPBQfVbsB3gEqSNv X-Proofpoint-GUID: 2Mi9oE77b3pVryyDgPBQfVbsB3gEqSNv Subject: RE: [PATCH] Fix-for-multiple-thread-detection-in-AIX.patch 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-08-01_07,2022-08-01_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 priorityscore=1501 impostorscore=0 adultscore=0 suspectscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 malwarescore=0 phishscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2208010085 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: , From: Aditya Kamath1 via Gdb-patches Reply-To: Aditya Kamath1 Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi all, Kindly let me know feedback for the patch in the previous mail. Thanks and regards, Aditya ________________________________ From: Gdb-patches on behalf of Aditya Kamath1 via Gdb-patches Sent: 29 July 2022 14:53 To: Simon Marchi ; Ulrich Weigand ; Sangamesh Mallayya ; simon.marchi@efficio= s.com ; gdb-patches@sourceware.org Subject: [EXTERNAL] RE: [PATCH] Fix-for-multiple-thread-detection-in-AIX.pa= tch Hi all, I thank you for the feedback that was given. It was a nice insight. Please find attached the new patch. [See Fix-for-multiple-thread-detection-= in-AIX.patch ] However, there are a few things that we had to look in further to what was = suggested. Here are my explanations to what was suggested. > I still think the proposed fix isn't really ideal. Can you instead > try to *temporarily* (i.e. using a scoped_restore) set up inferior_ptid > in pd_activate() before calling pthdb_session_init(), with a comment > explaining that this is needed for the callbacks? This is a nice idea Ulrich and Simon. However, let me take a case of a prog= ram creating 2 threads plus OfCourse having a main thread. Let's say the pr= ogram creates the first thread. This solution works fantastic. So, what is the problem with it?? We have our pd_active set to 1 in pd_act= ivate(). So, the next time we get into the wait() of aix-thread.c on an eve= nt of a new thread, what happens is since pthread debug library is initiali= sed we need not get into pd_activate() again to initialise. Therefore, this= condition : if (!pd_active && status->kind () =3D=3D TARGET_WAITKIND_STOPPED && status->sig () =3D=3D GDB_SIGNAL_TRAP) was made... We directly go to the pd_update().. Since the sync_threadlists(= ) also have pthread debug library functions and our current thread is also = null, we end up syncing threadlists with null thread which means our debug= ger will not reflect the new threads at all or if it does we will get an as= sertion saying "Assertion `ecs->event_thread->control.trap_expected' failed= " simply because only the thread which is allowed to step should create a t= rap and we on a creation of new thread said to the gdb core that null threa= d is the one who raised the event of new thread creation and hence the trap= .. So, what can be the solution?? It is great if we create a scope and tempora= rily switch our thread just before you pthdb_session init() in pd_activate(= ) whicj takes care of session initialisation and just before the sync_threa= dlists() in pd_activate() post which sync threadlists() can give us the rig= ht thread who caused an event to the gdb core .. Kindly see the patch for the same with comments and inferior_ptid.pid () sp= ace correction is also made which I needed to as per Simon. Let me know what you think, if not let's push this so that AIX folks can de= bug with multiple threads. ---------------------------------------------------------------------------= ------------------- >>To avoid this kind of problems, you can temporarily >>switch thread (using scoped_restore_current_thread + switch_to_thread), >>which will set all the current stuff mentioned above. But sometimes >>this isn't possible, especially in thw wait method, because there isn't >>always a thread_info for the ptid you are handling yet, so you can't >>switch to it. Since you all are more experienced than me, I am sure the future issues and= solutions will be brightly more visible to all of you than me and I would = love to learn that.. Having said that let me assume you might be thinking o= f a fork() event where in case we return the child process ID and we switch= _to_thread(current_target, child_ptid) we might get an assertion saying inf= ->thread does not exist and rightly so.. That is where the APIs or function= s like ourstatus->set_forked(child_ptid) come in picture where we can pass = a new process info and then return a parent process ptid who has a thread f= rom beneath->wait to aix_thread:wait() and that way we won't face this issu= e of having an inferior with no thread when we use switch_to_thread(current= _target,ptid) in AIX for the time being at least.. Hopefully we are thinking in the same terms and the solution for multiple t= hreads is fair. Have a nice day ahead. Thank you, Regards, Aditya. ________________________________ From: Simon Marchi Sent: 25 July 2022 21:00 To: Ulrich Weigand ; Sangamesh Mallayya ; Aditya Kamath1 ; simon.marchi= @efficios.com ; gdb-patches@sourceware.org Subject: [EXTERNAL] Re: [PATCH] Fix-for-multiple-thread-detection-in-AIX.pa= tch On 2022-07-25 08:21, Ulrich Weigand wrote: > > Aditya Kamath1 wrote: > >> The cause of the bug :- Since, for the GDB core we are >> switch_to_no_thread() i.e. we do not have a thread till we return the >> pid from the wait() there is no thread. So, when a call is made from >> pd_activate() in wait() of aix-thread.c, to pthdb_session_init() we are >> going to recieve PTHDB_NOT_THREADED. > > Thanks for the explanation. I wasn't aware the use of > inferior_ptid happens in some of callback routines used > by the pthdb_session_init() library routine. Thanks, me neither, but it makes sense. > I still think the proposed fix isn't really ideal. Can you instead > try to *temporarily* (i.e. using a scoped_restore) set up inferior_ptid > in pd_activate() before calling pthdb_session_init(), with a comment > explaining that this is needed for the callbacks? That sounds like a good idea, this way, from the point of view of the caller of pd_activate, pd_activate does not care about global state. That's how we can do baby steps towards relying less on global state implicitly. The next step could be to try to make each individual callback switch to the right global context, based on what they need. You just need to be careful, some parts of GDB expect inferior_ptid, the current thread, the current inferior and the current program space to be sync'ed. If you just set inferior_ptid, you need to make sure to only call functions that use inferior_ptid, not the other current stuff. There is not practical way to know this, you have to carefully inspect what is called. To avoid this kind of problems, you can temporarily switch thread (using scoped_restore_current_thread + switch_to_thread), which will set all the current stuff mentioned above. But sometimes this isn't possible, especially in thw wait method, because there isn't always a thread_info for the ptid you are handling yet, so you can't switch to it. Given the AIX target only supports one inferior for now, the current inferior and program space should be correct. But to support multi-inferior, it will be important to keep that in mind. You might have to switch to the right inferior in addition to setting inferior_ptid in pd_acticate. This hunk in the patch: diff --git a/gdb/aix-thread.c b/gdb/aix-thread.c index 4c9195a7f12..91466a17647 100644 --- a/gdb/aix-thread.c +++ b/gdb/aix-thread.c @@ -976,7 +976,7 @@ pd_enable (void) /* If we're debugging a core file or an attached inferior, the pthread library may already have been initialized, so try to activate thread debugging. */ - pd_activate (1); + pd_activate (inferior_ptid.pid()); } looks right to me (except the missing space before the parenthesis). It looks like an oversight in my "gdb: fix {rs6000_nat_target,aix_thread_target}::wait to not use inferior_ptid" patch, I forgot to update that call to pd_activate. Note that the old parameter to pd_activate was SET_INFPID, and if set, pd_update would change the current thread to reflect the thread ptid, if thread debugging was enabled. The current code no longer does that. If that was important, we can re-introduce it here: make pd_enable switch to the thread with the ptid returned by pd_activate. Simon