From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <442C19F2.206@domain.hid> Date: Thu, 30 Mar 2006 12:48:34 -0500 From: Sean McGranaghan MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Xenomai-help] rt_task_delete() question List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: xenomai@xenomai.org Hello all, I am posting this for a co-worker who is having problems with killing a real-time task. (He is joining the email list shortly but for now I will pass responses on to him.) Here is the scenario: 1. A Linux process starts up and detaches from the tty (daemon) 2. The daemon creates a xeno message queue 2. The daemon spawns a xeno task 3. The xeno task on startup binds to the queue rt_queue_bind() 4. The xeno task waits on the queue recv with infinite timeout 5. The daemon process goes to sleep in a join, waiting for the task to exit 6. Some time later another program starts 7. The other non-realtime program looks up the xeno task name via rt_task_bind() 8. The other non-realtime program attempts to delete the task via rt_task_delete() Failed Attempt #1 - Non-realtime program calls rt_task_delete() and gets a segmentation fault Failed Attempt #2 - Non-realtime program spawns a realtime task which binds to original task and tries rt_task_delete(). Also gets segmentation fault. The was attempted one a system running the latest Xenomai 2.1 release. What is the preferred method to start/join threads from a non-realtime context? Any help is appreciated.
From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <442C42B5.2070506@domain.hid> Date: Thu, 30 Mar 2006 22:42:29 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Xenomai-help] rt_task_delete() question References: <442C19F2.206@domain.hid> In-Reply-To: <442C19F2.206@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8F5BAB9191E59D4CE889F4BB" Sender: jan.kiszka@domain.hid List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sean McGranaghan Cc: xenomai@xenomai.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8F5BAB9191E59D4CE889F4BB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sean McGranaghan wrote: > Hello all, >=20 > I am posting this for a co-worker who is having problems with killing a= =20 > real-time task. (He is joining the email list shortly but for now I wil= l pass=20 > responses on to him.) Here is the scenario: >=20 > 1. A Linux process starts up and detaches from the tty (daemon) > 2. The daemon creates a xeno message queue > 2. The daemon spawns a xeno task > 3. The xeno task on startup binds to the queue rt_queue_bind() > 4. The xeno task waits on the queue recv with infinite timeout > 5. The daemon process goes to sleep in a join, waiting for the task to = exit > 6. Some time later another program starts > 7. The other non-realtime program looks up the xeno task name via rt_ta= sk_bind() > 8. The other non-realtime program attempts to delete the task via rt_ta= sk_delete() > Failed Attempt #1 - Non-realtime program calls rt_task_delete()= and gets > a segmentation fault > Failed Attempt #2 - Non-realtime program spawns a realtime task= which > binds to original task and tries rt_task_de= lete(). > Also gets segmentation fault. >=20 > The was attempted one a system running the latest Xenomai 2.1 release. >=20 > What is the preferred method to start/join threads from a non-realtime = context? >=20 > Any help is appreciated. >=20 rt_task_delete is not supposed to work across processes (Hmm, is this detail documented somewhere?). Use a normal Linux signal (e.g. SIGTERM) to terminate the daemon process. For a clean termination, you should install a signal handler in the daemon process which triggers an organised clean-up (all RT-resources except tasks have to be released explicitly). Jan --------------enig8F5BAB9191E59D4CE889F4BB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFELEK1niDOoMHTA+kRAqGRAJwNI+ogOYQ9WUky7H8YtZwB58ie1QCdF+Zq Z4zAjm4UZVdb7z9VvSI3xH4= =Tzip -----END PGP SIGNATURE----- --------------enig8F5BAB9191E59D4CE889F4BB-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <442C4816.6030509@domain.hid> Date: Thu, 30 Mar 2006 23:05:26 +0200 From: Philippe Gerum MIME-Version: 1.0 Subject: Re: [Xenomai-help] rt_task_delete() question References: <442C19F2.206@domain.hid> <442C42B5.2070506@domain.hid> In-Reply-To: <442C42B5.2070506@domain.hid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai@xenomai.org Jan Kiszka wrote: > Sean McGranaghan wrote: > >>Hello all, >> >>I am posting this for a co-worker who is having problems with killing a >>real-time task. (He is joining the email list shortly but for now I will pass >>responses on to him.) Here is the scenario: >> >>1. A Linux process starts up and detaches from the tty (daemon) >>2. The daemon creates a xeno message queue >>2. The daemon spawns a xeno task >>3. The xeno task on startup binds to the queue rt_queue_bind() >>4. The xeno task waits on the queue recv with infinite timeout >>5. The daemon process goes to sleep in a join, waiting for the task to exit >>6. Some time later another program starts >>7. The other non-realtime program looks up the xeno task name via rt_task_bind() >>8. The other non-realtime program attempts to delete the task via rt_task_delete() >> Failed Attempt #1 - Non-realtime program calls rt_task_delete() and gets >> a segmentation fault >> Failed Attempt #2 - Non-realtime program spawns a realtime task which >> binds to original task and tries rt_task_delete(). >> Also gets segmentation fault. >> >>The was attempted one a system running the latest Xenomai 2.1 release. >> >>What is the preferred method to start/join threads from a non-realtime context? >> >>Any help is appreciated. >> > > > rt_task_delete is not supposed to work across processes (Hmm, is this > detail documented somewhere?). > Nope, basically because I totally overlooked the issue... but we should make this possible, since rt_task_suspend() is already system-scoped. Ok, this one is on my todo list. > Use a normal Linux signal (e.g. SIGTERM) to terminate the daemon > process. For a clean termination, you should install a signal handler in > the daemon process which triggers an organised clean-up (all > RT-resources except tasks have to be released explicitly). > > Jan > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Xenomai-help mailing list > Xenomai-help@domain.hid > https://mail.gna.org/listinfo/xenomai-help -- Philippe. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <442D02CD.6080508@domain.hid> Date: Fri, 31 Mar 2006 12:22:05 +0200 From: Philippe Gerum MIME-Version: 1.0 Subject: Re: [Xenomai-help] rt_task_delete() question References: <442C19F2.206@domain.hid> In-Reply-To: <442C19F2.206@domain.hid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sean McGranaghan Cc: xenomai@xenomai.org Sean McGranaghan wrote: > Hello all, > > I am posting this for a co-worker who is having problems with killing a > real-time task. (He is joining the email list shortly but for now I will > pass responses on to him.) Here is the scenario: > > 1. A Linux process starts up and detaches from the tty (daemon) > 2. The daemon creates a xeno message queue > 2. The daemon spawns a xeno task > 3. The xeno task on startup binds to the queue rt_queue_bind() > 4. The xeno task waits on the queue recv with infinite timeout > 5. The daemon process goes to sleep in a join, waiting for the task to exit > 6. Some time later another program starts > 7. The other non-realtime program looks up the xeno task name via > rt_task_bind() > 8. The other non-realtime program attempts to delete the task via > rt_task_delete() > Failed Attempt #1 - Non-realtime program calls rt_task_delete() > and gets > a segmentation fault > Failed Attempt #2 - Non-realtime program spawns a realtime task > which > binds to original task and tries > rt_task_delete(). > Also gets segmentation fault. > Eeek... 100% reproducible here. Blatant bug. More later. Thanks for reporting. > The was attempted one a system running the latest Xenomai 2.1 release. > > What is the preferred method to start/join threads from a non-realtime > context? > > Any help is appreciated. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Xenomai-help mailing list > Xenomai-help@domain.hid > https://mail.gna.org/listinfo/xenomai-help -- Philippe. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <442D1CAD.3030007@domain.hid> Date: Fri, 31 Mar 2006 07:12:29 -0500 From: Sean McGranaghan MIME-Version: 1.0 Subject: Re: [Xenomai-help] rt_task_delete() question References: <442C19F2.206@domain.hid> <442C42B5.2070506@domain.hid> <442C4816.6030509@domain.hid> In-Reply-To: <442C4816.6030509@domain.hid> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Gerum Cc: xenomai@xenomai.org, Jan Kiszka Thanks for the quick response. We will use the signal work around for now.

Sean

Philippe Gerum wrote:

Jan Kiszka wrote:

Sean McGranaghan wrote:

Hello all,

I am posting this for a co-worker who is having problems with killing a real-time task. (He is joining the email list shortly but for now I will pass responses on to him.) Here is the scenario:

1. A Linux process starts up and detaches from the tty (daemon)
2. The daemon creates a xeno message queue
2. The daemon spawns a xeno task
3. The xeno task on startup binds to the queue rt_queue_bind()
4. The xeno task waits on the queue recv with infinite timeout
5. The daemon process goes to sleep in a join, waiting for the task to exit
6. Some time later another program starts
7. The other non-realtime program looks up the xeno task name via rt_task_bind()
8. The other non-realtime program attempts to delete the task via rt_task_delete()
       Failed Attempt #1 - Non-realtime program calls rt_task_delete() and gets
                           a segmentation fault
       Failed Attempt #2 - Non-realtime program spawns a realtime task which
                           binds to original task and tries rt_task_delete().
                           Also gets segmentation fault.

The was attempted one a system running the latest Xenomai 2.1 release.

What is the preferred method to start/join threads from a non-realtime context?

Any help is appreciated.

rt_task_delete is not supposed to work across processes (Hmm, is this
detail documented somewhere?).

Nope, basically because I totally overlooked the issue... but we should make this possible, since rt_task_suspend() is already system-scoped. Ok, this one is on my todo list.

Use a normal Linux signal (e.g. SIGTERM) to terminate the daemon
process. For a clean termination, you should install a signal handler in
the daemon process which triggers an organised clean-up (all
RT-resources except tasks have to be released explicitly).

Jan

------------------------------------------------------------------------

_______________________________________________
Xenomai-help mailing list
Xenomai-help@domain.hid
https://mail.gna.org/listinfo/xenomai-help

From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <442D3AC8.3080806@domain.hid> Date: Fri, 31 Mar 2006 16:20:56 +0200 From: Philippe Gerum MIME-Version: 1.0 Subject: Re: [Xenomai-help] rt_task_delete() question References: <442C19F2.206@domain.hid> <442D02CD.6080508@domain.hid> In-Reply-To: <442D02CD.6080508@domain.hid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Philippe Gerum Cc: xenomai@xenomai.org Philippe Gerum wrote: > Sean McGranaghan wrote: > >> Hello all, >> >> I am posting this for a co-worker who is having problems with killing >> a real-time task. (He is joining the email list shortly but for now I >> will pass responses on to him.) Here is the scenario: >> >> 1. A Linux process starts up and detaches from the tty (daemon) >> 2. The daemon creates a xeno message queue >> 2. The daemon spawns a xeno task >> 3. The xeno task on startup binds to the queue rt_queue_bind() >> 4. The xeno task waits on the queue recv with infinite timeout >> 5. The daemon process goes to sleep in a join, waiting for the task to >> exit >> 6. Some time later another program starts >> 7. The other non-realtime program looks up the xeno task name via >> rt_task_bind() >> 8. The other non-realtime program attempts to delete the task via >> rt_task_delete() >> Failed Attempt #1 - Non-realtime program calls >> rt_task_delete() and gets >> a segmentation fault >> Failed Attempt #2 - Non-realtime program spawns a realtime >> task which >> binds to original task and tries >> rt_task_delete(). >> Also gets segmentation fault. >> > > Eeek... 100% reproducible here. Blatant bug. More later. Thanks for > reporting. > >> The was attempted one a system running the latest Xenomai 2.1 release. >> >> What is the preferred method to start/join threads from a non-realtime >> context? >> >> Any help is appreciated. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Xenomai-help mailing list >> Xenomai-help@domain.hid >> https://mail.gna.org/listinfo/xenomai-help > > > Fixed in the trunk/ and 2.1 maintenance branches (commits #827 and #828). The attached patch should apply properly on 2.1.0 with only a few hunks. Index: src/skins/native/task.c =================================================================== --- src/skins/native/task.c (revision 822) +++ src/skins/native/task.c (working copy) @@ -212,7 +212,7 @@ { int err; - if (task) { + if (task && task->opaque2) { err = pthread_cancel((pthread_t)task->opaque2); if (err) return -err; @@ -349,6 +349,9 @@ int rt_task_join (RT_TASK *task) { + if (!task->opaque2) + return -ESRCH; + return -pthread_join((pthread_t)task->opaque2, NULL); } Index: ksrc/skins/native/syscall.c =================================================================== --- ksrc/skins/native/syscall.c (revision 822) +++ ksrc/skins/native/syscall.c (working copy) @@ -207,7 +207,12 @@ err = __rt_bind_helper(curr,regs,&ph.opaque,XENO_TASK_MAGIC,NULL); if (!err) + { + /* We just don't know the associated user-space pthread + identifier -- clear it to prevent misuse. */ + ph.opaque2 = 0; __xn_copy_to_user(curr,(void __user *)__xn_reg_arg1(regs),&ph,sizeof(ph)); + } return err; } Index: ksrc/nucleus/shadow.c =================================================================== --- ksrc/nucleus/shadow.c (revision 822) +++ ksrc/nucleus/shadow.c (working copy) @@ -327,7 +327,14 @@ case LO_SIGNAL_REQ: - send_sig(rq->req[reqnum].arg,p,1); + /* Special case: SIGKILL should always be sent to the + entire thread group. */ + + if (rq->req[reqnum].arg == SIGKILL) + kill_proc(p->pid,SIGKILL,1); + else + send_sig(rq->req[reqnum].arg,p,1); + break; } } @@ -790,7 +797,7 @@ xnpod_fatal("xnshadow_unmap() called from invalid context"); #endif /* CONFIG_XENO_OPT_DEBUG */ - p = xnthread_archtcb(thread)->user_task; + p = xnthread_archtcb(thread)->user_task; /* May be != current */ magic = xnthread_get_magic(thread); @@ -819,11 +826,11 @@ if (p->state != TASK_RUNNING) { /* If the shadow is being unmapped in primary mode or blocked - in secondary mode, the associated Linux task should also - die. In the former case, the zombie Linux side returning to - user-space will be trapped and exited inside the pod's - rescheduling routines. */ - schedule_linux_call(LO_WAKEUP_REQ,p,0); + in secondary mode, the entire thread group associated with + the mapped task should also die. In the former case, the + zombie Linux side returning to user-space will be trapped + and exited inside the pod's rescheduling routines. */ + schedule_linux_call(LO_SIGNAL_REQ,p,SIGKILL); return; } -- Philippe.