[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110807073224.GG132@brightrain.aerifal.cx>
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.
