Re: [Xenomai-help] Howto catch SEGV signals in Xenomai

[Philippe Gerum <rpm@xenomai.org>]

On Tue, 2007-03-13 at 23:34 +0100, Philippe Gerum wrote:
> On Tue, 2007-03-13 at 20:21 +0100, Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> >  > On Tue, 2007-03-13 at 16:25 +0100, Gilles Chanteperdrix wrote:
> >  > > M. Koehrer wrote:
> >  > > > Hi all,
> >  > > > 
> >  > > > I have a problem to catch segment violations with Xenomai:
> >  > > > For demonstration I use the following program:
> >  > > > ------------------------------------------
> >  > > > #include <stdio.h>
> >  > > > #include <sys/mman.h>
> >  > > > 
> >  > > > #include <native/task.h>
> >  > > > #include <native/sem.h>
> >  > > > RT_TASK taska_desc;
> >  > > > volatile int *pointer = 0;
> >  > > > 
> >  > > > void mytaska(void *cookie)
> >  > > > {
> >  > > >     int i;
> >  > > >     for (i=0; i < 50; i++)
> >  > > >     {
> >  > > >         rt_task_sleep(50000000);
> >  > > >         if (i > 20)
> >  > > >         {
> >  > > >             *pointer = 123;
> >  > > >         }
> >  > > >         printf("Hello %i\n", i);
> >  > > >     }
> >  > > >     printf("Hi, this is task A\n");
> >  > > > }
> >  > > > 
> >  > > > int main(void)
> >  > > > {
> >  > > >     mlockall(MCL_CURRENT|MCL_FUTURE);
> >  > > > 
> >  > > >     rt_task_create(&taska_desc, "mytaska", 0, 81, T_JOINABLE);
> >  > > >     rt_task_start(&taska_desc, &mytaska, NULL);
> >  > > > 
> >  > > >     rt_task_join(&taska_desc);
> >  > > >     printf("Main: A joined\n");
> >  > > > 
> >  > > >     return 0;
> >  > > > }
> >  > > > ---------------------------------------
> >  > > > Whenever i is greater than 20 a segment violation occurs, as I must not write
> >  > > > to address 0 (the pointer is always NULL).
> >  > > > However, what happens is, that my system freezes after printing out 18 or 19.
> >  > > > I have to reset the PC to continue.
> >  > > > When I write a printf() directly before the invalid assignment I get the usual linux
> >  > > > "segmentation fault" error message.
> >  > > > 
> >  > > > How can I catch a signal in a Xenomai real time task?
> >  > > > 
> >  > > > I am running Xenomai 2.3.0 + NOCOW patch.
> >  > > > 
> >  > > > I have enclosed the .c file and a Makefile in a .tgz file.
> >  > > > 
> >  > > > Thanks for any feedback on that issue
> >  > > 
> >  > > It looks like the "relaxing a kicked thread" issue again. Could you try
> >  > > the attached patch ?
> >  > > 
> >  > 
> >  > Gasp. This patch would contradict what's going on into
> >  > do_sigwake_event(); well, if you are right, we would have entered the
> >  > twilight zone with full ignition of the auxiliary boosters.
> >  > 
> >  > Btw, XNRELAX is a state bit, not an information one. i.e.
> >  > 
> >  > -               if (xnthread_test_info(thread, XNKICKED)) {
> >  > +               if (xnthread_test_info(thread, XNKICKED) && !xnthread_test_state(thread, XNRELAX)) {
> > 
> > The code in do_sigwake_event() prevents a relaxed thread from being
> > kicked, but not the other way around. Who knows in what order
> > things get done on an SMP system ?
> > 
> 
> I still don't find any obvious issue there. I mean, if a thread is
> kicked, then it must have been unblocked from a sleep state in primary
> mode; that's the purpose of the related checks in do_sigwake_event().
> Since relaxing is a self-targeted operation (i.e. only a thread may
> relax itself, and no thread may direct a relaxing request to another
> one), then the unblocked thread must go through
> request_syscall_restart() first, on its way back from the blocking
> syscall, to the high stage syscall dispatcher. And all this exclusively
> runs in primary mode until request_syscall_restart() eventually relaxes
> the signaled thread.
> 
> IOW, I still don't see how a kicked thread would resume execution on a
> different CPU without first relaxing in request_syscall_restart(), which
> clears the XNKICKED bit in the first place, and as such would prevent
> the situation addressed by the previous patch.
> 
> Additionally, in case of a page fault causing the signal, the latter
> would be sent over the context of the faulting thread, i.e. on the same
> CPU, since we can't migrate threads at this point.
> 
> The best way to prove or contradict this analysis is to run the test
> code, pulling the brake in case I'm wrong. Please Mathias, could you try
> this on your system:
> 

Sorry, that one is better:

> --- ksrc/nucleus/pod.c	(revision 2293)
> +++ ksrc/nucleus/pod.c	(working copy)
> @@ -1420,6 +1420,11 @@
>  		   the KICKED bit set, so that xnshadow_relax() is never
>  		   prevented from blocking the current thread. */
>  		if (xnthread_test_info(thread, XNKICKED)) {
> +			XENO_ASSERT(NUCLEUS, (mask & XNRELAX) != 0,

+			XENO_ASSERT(NUCLEUS, (mask & XNRELAX) == 0,

> +				    xnpod_fatal("Relaxing a kicked thread"
> +						"(thread=%s, mask=%lx)?!",
> +						thread->name, mask);
> +				);
>  			xnthread_clear_info(thread, XNRMID | XNTIMEO);
>  			xnthread_set_info(thread, XNBREAK);
>  			goto unlock_and_exit;
> 
> 
-- 
Philippe.