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 53D523861038 for ; Thu, 20 May 2021 15:43:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 53D523861038 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14KFY4s5042947; Thu, 20 May 2021 11:42:51 -0400 Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0b-001b2d01.pphosted.com with ESMTP id 38nsh32mxk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 May 2021 11:42:51 -0400 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.16.0.43/8.16.0.43) with SMTP id 14KFYvRX008382; Thu, 20 May 2021 15:42:50 GMT Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by ppma05wdc.us.ibm.com with ESMTP id 38j7tbg358-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 May 2021 15:42:50 +0000 Received: from b01ledav001.gho.pok.ibm.com (b01ledav001.gho.pok.ibm.com [9.57.199.106]) by b01cxnp22034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 14KFgnKq31523230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 20 May 2021 15:42:49 GMT Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B524328077; Thu, 20 May 2021 15:42:47 +0000 (GMT) Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id ABDD42806F; Thu, 20 May 2021 15:42:46 +0000 (GMT) Received: from li-e362e14c-2378-11b2-a85c-87d605f3c641.ibm.com (unknown [9.211.90.242]) by b01ledav001.gho.pok.ibm.com (Postfix) with ESMTP; Thu, 20 May 2021 15:42:46 +0000 (GMT) Message-ID: <688f6c2f4f873e90d410c4e3b207cc20673aae1b.camel@us.ibm.com> Subject: Re: [PATCH] kill all threadapply processes at end of test From: Carl Love To: Pedro Franco de Carvalho , gdb-patches@sourceware.org Cc: ulrich.weigand@de.ibm.com, tom@tromey.com, simon.marchi@polymtl.ca, rogealve@br.ibm.com, cel@us.ibm.com, Will Schmidt Date: Thu, 20 May 2021 08:42:45 -0700 In-Reply-To: <875yzflgzs.fsf@linux.ibm.com> References: <87cztn7lk9.fsf@linux.ibm.com> <875yzflgzs.fsf@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-14.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: Nx4wTu5e83owEHtDoHv-ECWULlRW8yDd X-Proofpoint-ORIG-GUID: Nx4wTu5e83owEHtDoHv-ECWULlRW8yDd X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-20_04:2021-05-20, 2021-05-20 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 mlxscore=0 suspectscore=0 mlxlogscore=879 phishscore=0 lowpriorityscore=0 bulkscore=0 impostorscore=0 malwarescore=0 spamscore=0 priorityscore=1501 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105200104 X-Spam-Status: No, score=-6.2 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: Thu, 20 May 2021 15:43:01 -0000 Pedro: On Tue, 2021-05-18 at 21:11 -0300, Pedro Franco de Carvalho wrote: > 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. > Moving the detach code to the end of thr_apply_detach simplifies the patch significantly. The current busy loop runs a really long time relative to the length of the detatch tests. So I do think that is a very safe solution. The ptrace_barrier_wait approach is definitely more complex and could break the other tests as you described. I have not implemented this approach yet so I can say for sure what the issues may be. The issue is only with the detach tests so I can't see splitting the test into two tests and then using the barrier method on the other tests that don't have the issue of threads left running. It is making those tests more complex and not fixing an existing issue with those tests. I did move the re-attach thread code to the thr_apply_detach test and it does seem to work. I will post it for review and discussion of the pid recycling issue. Carl