From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47000 invoked by alias); 23 Oct 2017 23:43:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 46981 invoked by uid 89); 23 Oct 2017 23:43:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=completion, harness, terminating, love X-Spam-User: qpsmtpd, 2 recipients X-HELO: 20pmail.ess.barracuda.com Received: from 20pmail.ess.barracuda.com (HELO 20pmail.ess.barracuda.com) (64.235.154.232) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 23 Oct 2017 23:43:52 +0000 Received: from MIPSMAIL01.mipstec.com (mailrelay.mips.com [12.201.5.28]) by mx1412.ess.rzc.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 23 Oct 2017 23:42:48 +0000 Received: from [10.20.78.45] (10.20.78.45) by mips01.mipstec.com (10.20.43.31) with Microsoft SMTP Server id 14.3.361.1; Mon, 23 Oct 2017 16:41:53 -0700 Date: Mon, 23 Oct 2017 23:43:00 -0000 From: "Maciej W. Rozycki" To: Simon Marchi CC: Djordje Todorovic , Pedro Alves , , , , , , Subject: Re: [PATCH 3/3] Add test for fetching TLS from core file In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-BESS-ID: 1508802168-452060-6860-171149-1 X-BESS-VER: 2017.12.1-r1709122024 X-BESS-Apparent-Source-IP: 12.201.5.28 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.186237 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS59374 scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status:1 X-SW-Source: 2017-10/txt/msg00734.txt.bz2 On Thu, 19 Oct 2017, Simon Marchi wrote: > > Also `while (1) sleep (10);' perhaps, so that you don't cause a race with > > the whole process terminating (I think `pthread_join (&threads[0], NULL);' > > would do too; I'm sure there are other ways as well to prevent from > > running to exit(2)). Overall please don't assume any particular thread > > scheduling characteristics of the underlying OS, and especially on SMP > > systems effects may be sometimes surprising. > > Just make sure to avoid an infinite loop, in case the inferior is somehow left > running after executing the test because of some bug somewhere. You can't guarantee overall a test program won't hang, loop, etc. due to a bug somewhere. The issue of lingering processes should IMHO be handled by assigning software run on the target a new session and then killing the process group on completion. I believe this is actually done already, as this is how expect's `spawn' works and I think we also have it handled for the remote case in the `gdbserver' test harness (but I'd love to get a confirmation here). How do you propose anyway, in the absence of an infinite wait/loop, to ensure that the process does not terminate before the test harness has done its processing? Maciej