[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E3F10C7.4060601@gmail.com>
Date: Mon, 08 Aug 2011 00:25:11 +0200
From: Luka Marčetić <paxcoder@...il.com>
To: musl@...ts.openwall.com
Subject: Re: New daily reports - debugging alloc.c still
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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
