Date: Sun, 7 Aug 2011 03:32:24 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: New daily reports - debugging alloc.c still 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. I suspect you're over-thinking it. For any pthread function that will block/wait (e.g. to obtain a lock), hitting it with a signal and checking for EINTR is not a difficult race condition. It's like hunting turtles with a sniper rifle. The target thread is just sitting there waiting for you to signal it. I would do something like this: 1. Tell the target thread to make the call that will block. 2. Sleep for a fraction of a second to give it time to wake up and make the call. 3. Send the signal. 4. Sleep again for a fraction of a second to give it time to get interrupted, if it's going to. 5. Do whatever's needed to unblock the call (e.g. if the thread is blocked on pthread_mutex_lock, unlock the mutex it's trying to lock). 6. Check the return value of the call to see whether it was 0 or EINTR (or possibly something else). 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. > * apply different tools on setuid.c to remove the hang, employ the > strategy from point one here as well > (in both cases, the program is trying to interrupt a child's function call) 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. > * go through alloc.c again, to hopefully get an idea of why there > are "unexpected features". By the way, buf.c is crashing for me in free(), which means something clobbered the heap. I think we discussed this before: allocating just the right amount of memory and waiting for a crash is not a valid test, because you've trashed the heap state at that point, and it might or might not be detectable due to UB. If you want to look for crashes you could follow the string functions test approach (mmap at least 2 pages, with a non-accessible page at the end) but I think it would probably work just as well just to allocate buffers that are a plenty large, pre-fill the buffer with a pattern, and make sure the pattern has not been clobbered past the zone the function was permitted to write to. (Note that the reason we needed the mmap thing for string functions was that we were not just testing for out-of-bounds writes but also out-of-bounds reads.) Rich
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.