Race condition on SIGCANCEL signal in POSIX timers

Khem Raj raj.khem at gmail.com
Tue Aug 28 16:57:40 UTC 2012


On Tue, Aug 28, 2012 at 12:16 AM, Carmelo AMOROSO
<carmelo.amoroso at st.com> wrote:
> 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.
>

please commit it upstream too.


More information about the uClibc mailing list