From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 9BDE7385800F for ; Wed, 19 May 2021 00:11:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9BDE7385800F Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14J04D7J176245; Tue, 18 May 2021 20:11:46 -0400 Received: from ppma04wdc.us.ibm.com (1a.90.2fa9.ip4.static.sl-reverse.com [169.47.144.26]) by mx0b-001b2d01.pphosted.com with ESMTP id 38mprdhb96-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 May 2021 20:11:45 -0400 Received: from pps.filterd (ppma04wdc.us.ibm.com [127.0.0.1]) by ppma04wdc.us.ibm.com (8.16.0.43/8.16.0.43) with SMTP id 14J06icE028635; Wed, 19 May 2021 00:11:45 GMT Received: from b03cxnp08028.gho.boulder.ibm.com (b03cxnp08028.gho.boulder.ibm.com [9.17.130.20]) by ppma04wdc.us.ibm.com with ESMTP id 38j5x9b0us-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 May 2021 00:11:45 +0000 Received: from b03ledav004.gho.boulder.ibm.com (b03ledav004.gho.boulder.ibm.com [9.17.130.235]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 14J0BhJ630802334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 May 2021 00:11:43 GMT Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EC74478064; Wed, 19 May 2021 00:11:42 +0000 (GMT) Received: from b03ledav004.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 76BD078068; Wed, 19 May 2021 00:11:41 +0000 (GMT) Received: from pedro.localdomain (unknown [9.77.135.55]) by b03ledav004.gho.boulder.ibm.com (Postfix) with SMTP; Wed, 19 May 2021 00:11:41 +0000 (GMT) Received: by pedro.localdomain (Postfix, from userid 1000) id 304953C0560; Tue, 18 May 2021 21:11:38 -0300 (-03) From: Pedro Franco de Carvalho To: cel@us.ibm.com, gdb-patches@sourceware.org Cc: ulrich.weigand@de.ibm.com, tom@tromey.com, simon.marchi@polymtl.ca, rogealve@br.ibm.com Subject: Re: [PATCH] kill all threadapply processes at end of test In-Reply-To: <87cztn7lk9.fsf@linux.ibm.com> References: <87cztn7lk9.fsf@linux.ibm.com> Date: Tue, 18 May 2021 21:11:35 -0300 Message-ID: <875yzflgzs.fsf@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 2wE-bo5vYPmhdYhQbmq-r-cLt3ZzXC_s X-Proofpoint-GUID: 2wE-bo5vYPmhdYhQbmq-r-cLt3ZzXC_s X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-18_11:2021-05-18, 2021-05-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 clxscore=1015 suspectscore=0 spamscore=0 bulkscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 lowpriorityscore=0 malwarescore=0 phishscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105180168 X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: Wed, 19 May 2021 00:11:56 -0000 Hi Carl, Another thing, regarding pthread_barrier_wait solution that Simon suggested. I'm not sure, but I think the idea would be to initialize a barrier with a count of as many threads as are created in the test, plus the main thread. Then you'd put a call to pthread_barrier_wait before the exit from the thread_function, and remove the busy loop. This will be called by all the created threads shortly after they are created, but they won't exit until the main itself thread also calls thread_function and then pthread_barrier_wait. Assuming the breakpoint in /* Break here */ for main happens before that, all threads will be alive for the test when threadapply.exp calls 'thread apply detach', and they will only exit after the detach, which would obviate the need for the busy loop. This would however probably break the previous test with the backtraces, like Simon said, because the backtrace could put the threads somewhere in the call to ptrace_barrier_wait, and it might be deeper than one call depending on the implementation. If you can find a way to make it also work with the barriers, and make sure that the other tests in threadapply also work, that would allow removing the busy loops for all test. But if that isn't possible to do for the other tests, if you just want to avoid having dangling threads, then one idea is to separate the detach part of the test into another test entirely, that uses the barrier and no busy loop, just for testing the detach case, or use another .c for this part of the threadapply test. Not sure if it would be acceptable to make a separate test. But the barrier would avoid having to deal with the pid recycling issue. Thanks! -- Pedro Franco de Carvalho Pedro Franco de Carvalho via Gdb-patches writes: > Hello, > > I didn't review the patch in detail, but one concern is that this could > cause a pid recycling issue. After expect gets the pid from the stopped > inferior, and the gdb under expect detaches from the inferior, it could > happen that the inferior finishes, there's lots and lots of processes in > the test system, and that same pid might get reused for a completely > different process, which GDB would attach to and kill, assuming it has > ptrace privileges over it. This might be unlikely, but it would be bad > for the testsuite to kill a random process in the system. I'm not sure > if there's an easy and portable solution to this. > > Apart from that, it might be simpler to do the attaching and killing > inside proc thr_apply_detach. > > Thanks, > Pedro Franco de Carvalho