Re: [Xenomai-core] [BUG] rt_task_delete kills caller

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2133 bytes --]

Jan Kiszka wrote:
> Jan Kiszka wrote:
>> Hi,
>>
>> I stumbled over a strange behaviour of rt_task_delete for a created, set
>> periodic, but non-started task. The process gets killed on invocation,
> 
> More precisely:
> 
> (gdb) cont
> Program received signal SIG32, Real-time event 32.
> 
> Weird. No kernel oops BTW.
> 
>> but only if rt_task_set_periodic was called with a non-zero start time.
>> Here is the demo code:
>>
>> #include <stdio.h>
>> #include <sys/mman.h>
>> #include <native/task.h>
>>
>> main()
>> {
>> 	RT_TASK task;
>>
>> 	mlockall(MCL_CURRENT|MCL_FUTURE);
>>
>> 	printf("rt_task_create=%d\n",
>> 		rt_task_create(&task, "task", 8192*4, 10, 0));
>>
>> 	printf("rt_task_set_periodic=%d\n",
>> 		rt_task_set_periodic(&task, rt_timer_read()+1, 100000));
>>
>> 	printf("rt_task_delete=%d\n",
>> 		rt_task_delete(&task));
>> }
>>
>> Once you skip rt_task_set_periodic or call it like this
>> rt_task_set_periodic(&task, TM_NOW, 100000), everything is fine. Tested
>> over trunk, but I guess over versions should suffer as well.
>>
>> I noticed that the difference seems to be related to the
>> xnpod_suspend_thread in xnpod_set_thread_periodic. That suspend is not
>> called on idate == XN_INFINITE. What is it for then, specifically if you
>> would call xnpod_suspend_thread(thread, xnpod_get_time()+period, period)
>> which should have the same effect like xnpod_suspend_thread(thread, 0,
>> period)?

That difference is clear to me now: set_periodic with a start date !=
XN_INFINITE means "suspend the task immediately until the provided
release date" (RTFM...) while date == XN_INFINITE means "keep the task
running and schedule the first release on now+period".

The actual problem seems to be related to sending SIGKILL on
rt_task_delete to the dying thread. This happens only in the failing
case. When xnpod_suspend_thread was not called, the thread seems to
self-terminate first so that rt_task_delete becomes a nop (no more task
registered at that point). I think we had this issue before. Was it
solved? [/me querying the archive now...]

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]