From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/358 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?THVrYSBNYXLEjWV0acSH?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: New daily reports - debugging alloc.c still Date: Mon, 08 Aug 2011 00:25:11 +0200 Message-ID: <4E3F10C7.4060601@gmail.com> References: <4E39C84F.8060705@gmail.com> <20110803224651.GB11437@openwall.com> <4E3A79B2.8090204@gmail.com> <4E3B331E.7050502@gmail.com> <4E3CC5AC.3070404@gmail.com> <4E3DFB5D.8040008@gmail.com> <20110807073224.GG132@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1312756050 22218 80.91.229.12 (7 Aug 2011 22:27:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 7 Aug 2011 22:27:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-359-gllmg-musl=m.gmane.org@lists.openwall.com Mon Aug 08 00:27:26 2011 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1QqBoc-0001MA-8P for gllmg-musl@lo.gmane.org; Mon, 08 Aug 2011 00:27:26 +0200 Original-Received: (qmail 28261 invoked by uid 550); 7 Aug 2011 22:27:25 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 28253 invoked from network); 7 Aug 2011 22:27:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=iYgkBvtupqSQbdS8v0HlushU9WjJW+mUxiIQMyM+GgU=; b=Z9p5YwBSH4XYcpBUvApTKA6nP/S7TUdsjFyM9N4WIL69ZpmATbHqG0xX5hAT+xjbsx OJtJGAMYoVweqmAUdOKe8iNaR+w9uAu+ovjNuD3JuBb+PgXlvyRxMXD/SQTyoY/5AvVK ZRKsQWB1EB8czA5LCflx4uZQSVBZIx6H58RVc= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Icedove/3.1.11 In-Reply-To: <20110807073224.GG132@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:358 Archived-At: Hey, On 08/07/2011 09:32 AM, Rich Felker wrote: > On Sun, Aug 07, 2011 at 04:41:33AM +0200, Luka Marčetić wrote: >> What the title says. >> >> Priorities: >> * figure out how to continue writing pthread_eintr.c so that it >> works regarless of the nr of cores, write as many of function tests >> as possible > It would really help if I could see your progress on this. Sorry, read it late, and then when I started responding, I had a need to at least fix some stuff I left hanging the last time I worked on pthread_eintr. I'll commit pthread_eintr.c shortly, but I should say that I've found a way to do it introducing usleep() into that while loop we talked about on IRC (the one that sends signals in order to try to get pthread_* to exit). I'll commit the collection containing a single test (pthread_create) shortly. > I would do something like this: > > 1. Tell the target thread to make the call that will block. I'll ask you about those functions that can be blocked in IRC (I don't believe pthread_create is one of them). > 2. Sleep for a fraction of a second to give it time to wake up and > make the call. Speaking of which: Do you know what would cause the compiler to warn me about usleep()? I compile with a C99 flag and those two POSIX/XOPEN flags from the Makefile. It is in SUSv4... > [...] > For calls which don't block, it's a lot harder to test and you may > need a race approach, but I would consider them very low priority for > testing, since a good implementation won't do anything that would > return EINTR here. I can do those that can block/wait first, then the rest. But anyway, I think the method I employed for pthread_create should work for non-blocking ones. > Would you like me to send you the setuid test I have working on my > system? It might need some tweaking to hit the race on single-core > machines but you're welcome to use it for ideas or as a starting > point. Nah, I'll fix it eventually. Thanks. [...] (I'll need to clarify some things from the rest with you before I can respond) Later, Luka P.S. I'll also commit the newer alloc.c, though it'll spit out random stuff as it is now.