Race condition on SIGCANCEL signal in POSIX timers

[Carmelo AMOROSO]

On 28/08/2012 9.07, mail654 at gmx.de wrote:
> Hi,
> 

Hi,

> [Please keep me on CC:, I'm not subscribed]
> 
> I'm working with current uClibc and had problems with POSIX timers.
> 
> I use the timer with SIGEV_THREAD to create one thread each timer event. It
> seems there is a race condition between the thread waiting on SIGCANCEL signal
> (timer_helper_thread in timer_routine.c) and the default signal handler for this
> signal.
> Many timer events will be lost, because they will be dequeued before
> rt_sigtimedwait() could catch it.
> 
> I found a change on creating the helper thread. (Please see:
> http://git.uclibc.org/uClibc/commit/libpthread/nptl/sysdeps/unix/sysv/linux/timer_routines.c?id=162cfaea20d807f0ae329efe39292a9b22593b41)
> 
> After reverting this change, it works for me as expected.
> Could anybody remember, why this change was necessary?
> 
> I think the comment is wrong:
> /*__sigaddset (&ss, SIGCANCEL); - already done by sigfillset */
> 
> Currently SIGCANCEL will not be blocked by sigfillset, I had to reenable the
> __sidaddset() comment.
> 
> I already asked Denys Vlasenko via mail, but didn't get an answer so far.
> 
> Because I'm not subscribed to your bugtracker (and not intent to do so), could
> anybody please report a bug against uClibc or did I miss something and this
> change make any sense?
> 
> 
> Thank you in advance,
> 
> Erik
> 

we have spotted this issue recently as well, indeed the modifications
you mentioned have introduced a regression.
I have the fix in the STLinux uClibc repo
(http://git.stlinux.com/?p=stm/uclibc.git;a=commit;h=1eed623153b5139c8b5dca08030b3a4a1838d4db).

It's on my list for upstream to uclibc.org as well.

Cheers,
Carmelo


> _______________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
> 
>