Jan Kiszka wrote:
[a few interruptions later]

Jan Kiszka wrote:

Rodrigo Rosenfeld Rosas wrote:

BTW, please, could someone confirm the rt_task_delete(NULL) bug in SVN?

Half-confirmed, there is something fishy. I'm struggling with the
debugger ATM, not sure yet who's wrong ;). It tells me rt_task_delete of
the skin module is entered with task != NULL...

...which turns out to be fine, just appears redundant to me when
comparing __rt_task_delete and rt_task_delete for the task=NULL case.

Anyway, leaving a native task with rt_task_delete(NULL) raises SIGKILL
to the whole process instead of just the task (pthread). This lets your
program terminate unexpectedly - I would say: a bug. And this doesn't
happen with 2.1?

It's a side-effect of a recent bug fix in ksrc/nucleus/shadow.c; now killing a thread raises a group signal wiping out the entire process. Ok, it's a bit drastic, will fix.

I guess the easiest way to solve this is to catch NULL in userspace and
call pthread_exit() in favour of the skin service (the POSIX skin uses
pthread_exit anyway), see attached patch. Someone just has to confirm
that there will be no problem hidden by this approach.

Passing NULL needs to work including from user-space; the kernel-space is ok with this, and the API must behave the same way regardless of the execution space. Should fix as needed.


PS: What's the reason for "if (err == -ESRCH) return 0" in
src/skins/native/task.c, rt_task_delete? Why is that error generate in
the first place if it is zeroed out here?


Index: src/skins/native/task.c
--- src/skins/native/task.c     (revision 923)
+++ src/skins/native/task.c     (working copy)
@@ -212,7 +212,10 @@ int rt_task_delete (RT_TASK *task)
     int err;
- if (task && task->opaque2) {
+    if (!task)
+       pthread_exit(NULL);
+    if (task->opaque2) {
        err = pthread_cancel((pthread_t)task->opaque2);
        if (err)
            return -err;



Xenomai-core mailing list

Reply via email to