|
From: Jeremy F. <je...@go...> - 2005-04-07 17:43:29
|
Paul Mackerras wrote:
>I'm getting assertion failures in sema_down and sema_up in
>coregrind/linux/sema.c in valgrind-2.4.0. Since core_os.h defines
>FUTEX_SEMA to 0, we are using the pipe-based semaphores, not the
>futex-based ones. (Why? do the futex-based ones not work?)
>
>
We still need to support 2.4, and the pipe code works well enough for
both 2.4 and 2.6 (I couldn't measure a performance difference).
>Looking at sema_up/down, I can't see how it can possibly work
>correctly in the presence of fork(). If the client does a fork(), we
>do a fork() too, while holding the semaphore. The parent and all its
>descendents end up using the same pipe (assuming they don't do an
>execv*), and after a fork, both parent and child will think they hold
>the token and are entitled to do an up. Consequently we can end up
>with lots of tokens in the pipe (and I see that happening).
>
>
No, that's not right. VG_(sceduler_init) calls registers
sched_fork_cleanup as a child atfork handler. sched_fork_cleanup, among
other things, reinitializes the semaphore with a new pipe so the process
has its own. Perhaps your fork() syscall handler isn't calling
VG_(do_atfork_*)?
J
|