Re: New daily reports - debugging alloc.c still

["Luka Marčetić" <paxcoder@gmail.com>]

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.