[Xenomai-help] rt_queue_read switch to secondary mode

[Xenomai-help] rt_queue_read switch to secondary mode

[Sunny Bhuller]

Hello,
  I am new to xenomai and was having a problem with the rt_queue_read call.  I am creating a new RT_TASK from my main program with:

rt_task_create(&task, NULL, 0 /* default stack size */, 5 /* priority */, T_FPU | T_JOINABLE);

Once the task has started I switch it to primary mode with:

rt_task_set_mode(0, T_PRIMARY | T_WARNSW, NULL);

Now if I call the rt_queue_read I catch the signal that specifies the system has switched to secondary mode.  Is there something fundamentally wrong with what I am doing?  I can post a more detailed explanation if required, thanks!

-- Sunny

Re: [Xenomai-help] rt_queue_read switch to secondary mode

[Philippe Gerum]

On Fri, 2006-10-20 at 14:50 -0600, Sunny Bhuller wrote:
> Hello,
>   I am new to xenomai and was having a problem with the rt_queue_read call.  I am creating a new RT_TASK from my main program with:
> 
> rt_task_create(&task, NULL, 0 /* default stack size */, 5 /* priority */, T_FPU | T_JOINABLE);
> 
> Once the task has started I switch it to primary mode with:
> 
> rt_task_set_mode(0, T_PRIMARY | T_WARNSW, NULL);

Forcing to primary is useless, every real-time task starts in primary
mode, regardless of the relevant skin.

> 
> Now if I call the rt_queue_read I catch the signal that specifies the system has switched to secondary mode.  Is there something fundamentally wrong with what I am doing?  I can post a more detailed explanation if required, thanks!
> 

There is no reason for rt_queue_read() to move the thread to secondary
mode. You should try running the app over GDB, and inspect the backtrace
when the signal is received; you might discover that some other code
does cause this, or you might discover that we indeed have a bug hiding
somewhere. Posting a simple but complete test code that reproduces the
issue unambiguously would help too.

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

Re: [Xenomai-help] rt_queue_read switch to secondary mode

[Sunny Bhuller]

Hi Philippe,
  I am including some code below that will produce the problem I am seeing.  I must be missing something because if remove the force to primary mode in the function task_procedure the signal will not be caught.  This tells me that without the rt_task_set_mode the task is starting off in secondary mode.  

//------ Start

#include <signal.h>
#include <sys/mman.h>
#include <inttypes.h>
#include <native/task.h>
#include <native/queue.h>


typedef struct {
	uint8_t data[1024]; 
} __attribute__((packed)) some_data;


void task_procedure(void *arg)
{
	RT_QUEUE *msq_q = (RT_QUEUE *)arg;
	rt_task_set_mode(0, T_PRIMARY | T_WARNSW, NULL);

	some_data data;

	rt_queue_read( msq_q, &data, sizeof ( some_data ), TM_NONBLOCK);	
	
}

void signal_handler(int sig)
{
	if (sig == SIGXCPU)
		printf("---!! uh oh, switched to secondary mode !!--\n");
}


int main(int argc, char *argv[])
{
	RT_QUEUE msg_q;
	RT_TASK msg_task;

    	mlockall(MCL_CURRENT | MCL_FUTURE);

	rt_task_set_mode(0, T_PRIMARY | T_WARNSW, NULL);

	signal(SIGXCPU, signal_handler);

	rt_queue_create( &msg_q, "phil_test", sizeof(some_data), Q_UNLIMITED, Q_FIFO | Q_SHARED );

        rt_task_create(&msg_task, NULL, 0, 5, T_FPU | T_JOINABLE);
	rt_task_start(&msg_task, &task_procedure, &msg_q );

	rt_task_join( &msg_task );
	rt_task_delete( &msg_task );
	rt_queue_delete( &msg_q );

	return 0;
}


//-------- END


----- Original Message -----
From: Philippe Gerum <rpm@xenomai.org>
Date: Friday, October 20, 2006 2:59 pm
Subject: Re: [Xenomai-help] rt_queue_read switch to secondary mode

> On Fri, 2006-10-20 at 14:50 -0600, Sunny Bhuller wrote:
> > Hello,
> >   I am new to xenomai and was having a problem with the 
> rt_queue_read call.  I am creating a new RT_TASK from my main 
> program with:
> > 
> > rt_task_create(&task, NULL, 0 /* default stack size */, 5 /* 
> priority */, T_FPU | T_JOINABLE);
> > 
> > Once the task has started I switch it to primary mode with:
> > 
> > rt_task_set_mode(0, T_PRIMARY | T_WARNSW, NULL);
> 
> Forcing to primary is useless, every real-time task starts in primary
> mode, regardless of the relevant skin.
> 
> > 
> > Now if I call the rt_queue_read I catch the signal that 
> specifies the system has switched to secondary mode.  Is there 
> something fundamentally wrong with what I am doing?  I can post a 
> more detailed explanation if required, thanks!
> > 
> 
> There is no reason for rt_queue_read() to move the thread to secondary
> mode. You should try running the app over GDB, and inspect the 
> backtracewhen the signal is received; you might discover that some 
> other code
> does cause this, or you might discover that we indeed have a bug 
> hidingsomewhere. Posting a simple but complete test code that 
> reproduces the
> issue unambiguously would help too.
> 
> > -- Sunny
> > 
> > 
> > 
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
> -- 
> Philippe.
> 
> 
> 

Re: [Xenomai-help] rt_queue_read switch to secondary mode

[Philippe Gerum]

On Fri, 2006-10-20 at 16:00 -0600, Sunny Bhuller wrote:
> Hi Philippe,
>   I am including some code below that will produce the problem I am seeing. 
> I must be missing something because if remove the force to primary mode in the
>  function task_procedure the signal will not be caught.  This tells me that
>  without the rt_task_set_mode the task is starting off in secondary mode.  
> 

The backtrace of your program is this one when SIGXCPU is caught:

(gdb) r
Starting program: /home/rpm/frags/secondary/main
[Thread debugging using libthread_db enabled]
[New Thread -1210504992 (LWP 18784)]
[New Thread -1209074768 (LWP 18787)]

Program received signal SIGXCPU, CPU time limit exceeded.
[Switching to Thread -1209074768 (zombie)]
0xb7f02634 in calloc () from /lib/ld-linux.so.2
(gdb) bt
#0  0xb7f02634 in calloc () from /lib/ld-linux.so.2
#1  0xb7ef9110 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#2  0xb7ef8b01 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#3  0xb7e93200 in _dl_open () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7efd43f in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#5  0xb7e92c6f in _dl_open () from /lib/tls/i686/cmov/libc.so.6
#6  0xb7e9548d in __libc_dlsym () from /lib/tls/i686/cmov/libc.so.6
#7  0xb7efd43f in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
#8  0xb7e954ee in __libc_dlopen_mode ()
from /lib/tls/i686/cmov/libc.so.6
#9  0xb7ed7398 in pthread_cancel_init ()
from /lib/tls/i686/cmov/libpthread.so.0
#10 0xb7ed74c1 in _Unwind_ForcedUnwind ()
from /lib/tls/i686/cmov/libpthread.so.0
#11 0xb7ed51f1 in __pthread_unwind ()
from /lib/tls/i686/cmov/libpthread.so.0
#12 0xb7ed1210 in pthread_exit ()
from /lib/tls/i686/cmov/libpthread.so.0
#13 0xb7ec832a in rt_task_trampoline (cookie=0xbfcbb750)
    at /home/rpm/xenomai-2.2.4/src/skins/native/task.c:93
#14 0xb7ed0240 in start_thread ()
from /lib/tls/i686/cmov/libpthread.so.0
#15 0xb7e5e29e in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb)

This means that the signal was sent as a result of performing a calloc()
call, during the late binding of some dynamic library on behalf of
pthread_exit(), which gets called as your real-time task exits
immediately after the non-blocking call to rt_queue_read(). So this is
ok. The following patch should better illustrate the issue:

--- main.c~	2006-10-21 00:15:19.000000000 +0200
+++ main.c	2006-10-21 00:27:52.000000000 +0200
@@ -18,7 +18,7 @@
         some_data data;
 
         rt_queue_read( msq_q, &data, sizeof ( some_data ), TM_NONBLOCK);        
-        
+	rt_task_suspend(NULL);
 }
 
 void signal_handler(int sig)

PS: the call to rt_task_set_mode() in the main() function always fails,
since the main routine is not a Xenomai-thread when started. Therefore,
the call - which requires to be invoked by Xenomai threads - always
returns with -EPERM. Note: this behaviour may differ depending on the
skin bound to the application; for instance, the POSIX skin
automatically promotes the main code as a Xenomai-controlled thread, but
the native skin does not (maybe we should, though).

-- 
Philippe.

Re: [Xenomai-help] rt_queue_read switch to secondary mode

[Sunny Bhuller]

Hi Philippe,

  I don't think the signal is occuring due to pthread_exit().  If you put the rt_queue_read call in a loop you will see that the signal occurs on every call to rt_queue_read.  

...
	while (1)
 	{
		rt_queue_read( msq_q, &data, sizeof ( some_data ), TM_NONBLOCK);
		rt_task_sleep((RTIME) 100000);
	}
...

  The back trace produced the following output for me.

(gdb) r
Starting program: /root/ipas/apps/skel/test
[Thread debugging using libthread_db enabled]
[New Thread -1211189568 (LWP 15101)]
[New Thread -1208869968 (LWP 15104)]

Program received signal SIGXCPU, CPU time limit exceeded.
[Switching to Thread -1208869968 (LWP 15104)]
0xffffe410 in ?? ()
(gdb) bt
#0  0xffffe410 in ?? ()
#1  0xb7f20fe8 in ?? ()
#2  0x00000400 in ?? ()
#3  0xb7f21010 in ?? ()
#4  0xb7ef2c72 in rt_queue_read () from /usr/xenomai/lib/libnative.so.0
#5  0x08048852 in task_procedure (arg=0xbf93a640) at test.cpp:23
#6  0xb7ef3141 in rt_task_trampoline () from /usr/xenomai/lib/libnative.so.0
#7  0xb7efb0fb in start_thread () from /lib/tls/libpthread.so.0
#8  0xb7da399e in clone () from /lib/tls/libc.so.6
(gdb)


  Let me know if you see something wrong.
-- Sunny





----- Original Message -----
From: Philippe Gerum <rpm@xenomai.org>
Date: Friday, October 20, 2006 5:11 pm
Subject: Re: [Xenomai-help] rt_queue_read switch to secondary mode

> On Fri, 2006-10-20 at 16:00 -0600, Sunny Bhuller wrote:
> > Hi Philippe,
> >   I am including some code below that will produce the problem I 
> am seeing. 
> > I must be missing something because if remove the force to 
> primary mode in the
> >  function task_procedure the signal will not be caught.  This 
> tells me that
> >  without the rt_task_set_mode the task is starting off in 
> secondary mode.  
> > 
> 
> The backtrace of your program is this one when SIGXCPU is caught:
> 
> (gdb) r
> Starting program: /home/rpm/frags/secondary/main
> [Thread debugging using libthread_db enabled]
> [New Thread -1210504992 (LWP 18784)]
> [New Thread -1209074768 (LWP 18787)]
> 
> Program received signal SIGXCPU, CPU time limit exceeded.
> [Switching to Thread -1209074768 (zombie)]
> 0xb7f02634 in calloc () from /lib/ld-linux.so.2
> (gdb) bt
> #0  0xb7f02634 in calloc () from /lib/ld-linux.so.2
> #1  0xb7ef9110 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
> #2  0xb7ef8b01 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
> #3  0xb7e93200 in _dl_open () from /lib/tls/i686/cmov/libc.so.6
> #4  0xb7efd43f in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
> #5  0xb7e92c6f in _dl_open () from /lib/tls/i686/cmov/libc.so.6
> #6  0xb7e9548d in __libc_dlsym () from /lib/tls/i686/cmov/libc.so.6
> #7  0xb7efd43f in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
> #8  0xb7e954ee in __libc_dlopen_mode ()
> from /lib/tls/i686/cmov/libc.so.6
> #9  0xb7ed7398 in pthread_cancel_init ()
> from /lib/tls/i686/cmov/libpthread.so.0
> #10 0xb7ed74c1 in _Unwind_ForcedUnwind ()
> from /lib/tls/i686/cmov/libpthread.so.0
> #11 0xb7ed51f1 in __pthread_unwind ()
> from /lib/tls/i686/cmov/libpthread.so.0
> #12 0xb7ed1210 in pthread_exit ()
> from /lib/tls/i686/cmov/libpthread.so.0
> #13 0xb7ec832a in rt_task_trampoline (cookie=0xbfcbb750)
>    at /home/rpm/xenomai-2.2.4/src/skins/native/task.c:93
> #14 0xb7ed0240 in start_thread ()
> from /lib/tls/i686/cmov/libpthread.so.0
> #15 0xb7e5e29e in clone () from /lib/tls/i686/cmov/libc.so.6
> (gdb)
> 
> This means that the signal was sent as a result of performing a 
> calloc()call, during the late binding of some dynamic library on 
> behalf of
> pthread_exit(), which gets called as your real-time task exits
> immediately after the non-blocking call to rt_queue_read(). So 
> this is
> ok. The following patch should better illustrate the issue:
> 
> --- main.c~	2006-10-21 00:15:19.000000000 +0200
> +++ main.c	2006-10-21 00:27:52.000000000 +0200
> @@ -18,7 +18,7 @@
>         some_data data;
> 
>         rt_queue_read( msq_q, &data, sizeof ( some_data ), 
> TM_NONBLOCK);        
> -        
> +	rt_task_suspend(NULL);
> }
> 
> void signal_handler(int sig)
> 
> PS: the call to rt_task_set_mode() in the main() function always 
> fails,since the main routine is not a Xenomai-thread when started. 
> Therefore,the call - which requires to be invoked by Xenomai 
> threads - always
> returns with -EPERM. Note: this behaviour may differ depending on the
> skin bound to the application; for instance, the POSIX skin
> automatically promotes the main code as a Xenomai-controlled 
> thread, but
> the native skin does not (maybe we should, though).
> 
> -- 
> Philippe.
> 
> 
> 

Re: [Xenomai-help] rt_queue_read switch to secondary mode

[Philippe Gerum]

On Fri, 2006-10-20 at 17:37 -0600, Sunny Bhuller wrote:
> Hi Philippe,
> 
>   I don't think the signal is occuring due to pthread_exit().  If you put the rt_queue_read call in a loop you will see that the signal occurs on every call to rt_queue_read.  
> 
> ...
> 	while (1)
>  	{
> 		rt_queue_read( msq_q, &data, sizeof ( some_data ), TM_NONBLOCK);
> 		rt_task_sleep((RTIME) 100000);
> 	}
> ...

This code does not generate any mode switch here. Could you
display /proc/xenomai/stat once while the program runs?

Additionally, you may want to rebuild your user-space support by passing
--enable-debug to the configure script, so that we have better
backtraces.

Btw, what's your:
- platform?
- Adeos release?
- Xenomai version?

> 
>   The back trace produced the following output for me.
> 
> (gdb) r
> Starting program: /root/ipas/apps/skel/test
> [Thread debugging using libthread_db enabled]
> [New Thread -1211189568 (LWP 15101)]
> [New Thread -1208869968 (LWP 15104)]
> 
> Program received signal SIGXCPU, CPU time limit exceeded.
> [Switching to Thread -1208869968 (LWP 15104)]
> 0xffffe410 in ?? ()
> (gdb) bt
> #0  0xffffe410 in ?? ()
> #1  0xb7f20fe8 in ?? ()
> #2  0x00000400 in ?? ()
> #3  0xb7f21010 in ?? ()
> #4  0xb7ef2c72 in rt_queue_read () from /usr/xenomai/lib/libnative.so.0
> #5  0x08048852 in task_procedure (arg=0xbf93a640) at test.cpp:23
> #6  0xb7ef3141 in rt_task_trampoline () from /usr/xenomai/lib/libnative.so.0
> #7  0xb7efb0fb in start_thread () from /lib/tls/libpthread.so.0
> #8  0xb7da399e in clone () from /lib/tls/libc.so.6
> (gdb)
> 
> 
>   Let me know if you see something wrong.
> -- Sunny
> 
> 
> 
> 
> 
> ----- Original Message -----
> From: Philippe Gerum <rpm@xenomai.org>
> Date: Friday, October 20, 2006 5:11 pm
> Subject: Re: [Xenomai-help] rt_queue_read switch to secondary mode
> 
> > On Fri, 2006-10-20 at 16:00 -0600, Sunny Bhuller wrote:
> > > Hi Philippe,
> > >   I am including some code below that will produce the problem I 
> > am seeing. 
> > > I must be missing something because if remove the force to 
> > primary mode in the
> > >  function task_procedure the signal will not be caught.  This 
> > tells me that
> > >  without the rt_task_set_mode the task is starting off in 
> > secondary mode.  
> > > 
> > 
> > The backtrace of your program is this one when SIGXCPU is caught:
> > 
> > (gdb) r
> > Starting program: /home/rpm/frags/secondary/main
> > [Thread debugging using libthread_db enabled]
> > [New Thread -1210504992 (LWP 18784)]
> > [New Thread -1209074768 (LWP 18787)]
> > 
> > Program received signal SIGXCPU, CPU time limit exceeded.
> > [Switching to Thread -1209074768 (zombie)]
> > 0xb7f02634 in calloc () from /lib/ld-linux.so.2
> > (gdb) bt
> > #0  0xb7f02634 in calloc () from /lib/ld-linux.so.2
> > #1  0xb7ef9110 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
> > #2  0xb7ef8b01 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
> > #3  0xb7e93200 in _dl_open () from /lib/tls/i686/cmov/libc.so.6
> > #4  0xb7efd43f in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
> > #5  0xb7e92c6f in _dl_open () from /lib/tls/i686/cmov/libc.so.6
> > #6  0xb7e9548d in __libc_dlsym () from /lib/tls/i686/cmov/libc.so.6
> > #7  0xb7efd43f in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
> > #8  0xb7e954ee in __libc_dlopen_mode ()
> > from /lib/tls/i686/cmov/libc.so.6
> > #9  0xb7ed7398 in pthread_cancel_init ()
> > from /lib/tls/i686/cmov/libpthread.so.0
> > #10 0xb7ed74c1 in _Unwind_ForcedUnwind ()
> > from /lib/tls/i686/cmov/libpthread.so.0
> > #11 0xb7ed51f1 in __pthread_unwind ()
> > from /lib/tls/i686/cmov/libpthread.so.0
> > #12 0xb7ed1210 in pthread_exit ()
> > from /lib/tls/i686/cmov/libpthread.so.0
> > #13 0xb7ec832a in rt_task_trampoline (cookie=0xbfcbb750)
> >    at /home/rpm/xenomai-2.2.4/src/skins/native/task.c:93
> > #14 0xb7ed0240 in start_thread ()
> > from /lib/tls/i686/cmov/libpthread.so.0
> > #15 0xb7e5e29e in clone () from /lib/tls/i686/cmov/libc.so.6
> > (gdb)
> > 
> > This means that the signal was sent as a result of performing a 
> > calloc()call, during the late binding of some dynamic library on 
> > behalf of
> > pthread_exit(), which gets called as your real-time task exits
> > immediately after the non-blocking call to rt_queue_read(). So 
> > this is
> > ok. The following patch should better illustrate the issue:
> > 
> > --- main.c~	2006-10-21 00:15:19.000000000 +0200
> > +++ main.c	2006-10-21 00:27:52.000000000 +0200
> > @@ -18,7 +18,7 @@
> >         some_data data;
> > 
> >         rt_queue_read( msq_q, &data, sizeof ( some_data ), 
> > TM_NONBLOCK);        
> > -        
> > +	rt_task_suspend(NULL);
> > }
> > 
> > void signal_handler(int sig)
> > 
> > PS: the call to rt_task_set_mode() in the main() function always 
> > fails,since the main routine is not a Xenomai-thread when started. 
> > Therefore,the call - which requires to be invoked by Xenomai 
> > threads - always
> > returns with -EPERM. Note: this behaviour may differ depending on the
> > skin bound to the application; for instance, the POSIX skin
> > automatically promotes the main code as a Xenomai-controlled 
> > thread, but
> > the native skin does not (maybe we should, though).
> > 
> > -- 
> > Philippe.
> > 
> > 
> > 
> 
-- 
Philippe.

RE: [Xenomai-help] rt_queue_read switch to secondary mode

[Sunny]

Hi Philippe,

	I think I have solved the problem.  I was running

Linux v2.6.17.6  i686
Xenomai: v2.2.0
Adeos: adeos-ipipe-2.6.17.i386-1.3-08
Hardware: Pentium - M 


	Here is what I ended up doing:

1. Upgraded to Xenomai 2.2.4, but the problem still existed.  I ran gdb and
here is the backtrace result:
	------ GDB Backtrace w/ user space debug

	(gdb) r
	Starting program: /root/ipas/apps/skel/test
	[Thread debugging using libthread_db enabled]
	[New Thread -1211242816 (LWP 20349)]
	[New Thread -1208923216 (LWP 20352)]

	Program received signal SIGXCPU, CPU time limit exceeded.
	[Switching to Thread -1208923216 (LWP 20352)]
	0xb7ee5b8b in rt_queue_read (q=0xbfe6ab70, buf=0xb7f14000,
size=1024, timeout=18446744073709551615) at queue.c:164
	164             return XENOMAI_SKINCALL4(__native_muxid,
	Current language:  auto; currently c
	(gdb) bt
	#0  0xb7ee5b8b in rt_queue_read (q=0xbfe6ab70, buf=0xb7f14000,
size=1024, timeout=18446744073709551615) at queue.c:164
	#1  0x08048852 in task_procedure (arg=0xbfe6ab70) at test.cpp:23
	#2  0xb7ee6070 in rt_task_trampoline (cookie=0xbfe6ab70) at
task.c:89
	#3  0xb7eee0fb in start_thread () from /lib/tls/libpthread.so.0
	#4  0xb7d9699e in clone () from /lib/tls/libc.so.6


2. Installed adeos-ipipe-2.6.17-1.5-01
3. Set kernel option CONFIG_PREEMPT


	I no longer get the SIGXCPU switch.  Thanks for all of your help!

-- Sunny



-----Original Message-----
From: Philippe Gerum [mailto:rpm@xenomai.org] 
Sent: Friday, October 20, 2006 6:10 PM
To: sbhuller@domain.hid
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] rt_queue_read switch to secondary mode

On Fri, 2006-10-20 at 17:37 -0600, Sunny Bhuller wrote:
> Hi Philippe,
> 
>   I don't think the signal is occuring due to pthread_exit().  If you put
the rt_queue_read call in a loop you will see that the signal occurs on
every call to rt_queue_read.  
> 
> ...
> 	while (1)
>  	{
> 		rt_queue_read( msq_q, &data, sizeof ( some_data ),
TM_NONBLOCK);
> 		rt_task_sleep((RTIME) 100000);
> 	}
> ...

This code does not generate any mode switch here. Could you
display /proc/xenomai/stat once while the program runs?

Additionally, you may want to rebuild your user-space support by passing
--enable-debug to the configure script, so that we have better
backtraces.

Btw, what's your:
- platform?
- Adeos release?
- Xenomai version?

> 
>   The back trace produced the following output for me.
> 
> (gdb) r
> Starting program: /root/ipas/apps/skel/test
> [Thread debugging using libthread_db enabled]
> [New Thread -1211189568 (LWP 15101)]
> [New Thread -1208869968 (LWP 15104)]
> 
> Program received signal SIGXCPU, CPU time limit exceeded.
> [Switching to Thread -1208869968 (LWP 15104)]
> 0xffffe410 in ?? ()
> (gdb) bt
> #0  0xffffe410 in ?? ()
> #1  0xb7f20fe8 in ?? ()
> #2  0x00000400 in ?? ()
> #3  0xb7f21010 in ?? ()
> #4  0xb7ef2c72 in rt_queue_read () from /usr/xenomai/lib/libnative.so.0
> #5  0x08048852 in task_procedure (arg=0xbf93a640) at test.cpp:23
> #6  0xb7ef3141 in rt_task_trampoline () from
/usr/xenomai/lib/libnative.so.0
> #7  0xb7efb0fb in start_thread () from /lib/tls/libpthread.so.0
> #8  0xb7da399e in clone () from /lib/tls/libc.so.6
> (gdb)
> 
> 
>   Let me know if you see something wrong.
> -- Sunny
> 
> 
> 
> 
> 
> ----- Original Message -----
> From: Philippe Gerum <rpm@xenomai.org>
> Date: Friday, October 20, 2006 5:11 pm
> Subject: Re: [Xenomai-help] rt_queue_read switch to secondary mode
> 
> > On Fri, 2006-10-20 at 16:00 -0600, Sunny Bhuller wrote:
> > > Hi Philippe,
> > >   I am including some code below that will produce the problem I 
> > am seeing. 
> > > I must be missing something because if remove the force to 
> > primary mode in the
> > >  function task_procedure the signal will not be caught.  This 
> > tells me that
> > >  without the rt_task_set_mode the task is starting off in 
> > secondary mode.  
> > > 
> > 
> > The backtrace of your program is this one when SIGXCPU is caught:
> > 
> > (gdb) r
> > Starting program: /home/rpm/frags/secondary/main
> > [Thread debugging using libthread_db enabled]
> > [New Thread -1210504992 (LWP 18784)]
> > [New Thread -1209074768 (LWP 18787)]
> > 
> > Program received signal SIGXCPU, CPU time limit exceeded.
> > [Switching to Thread -1209074768 (zombie)]
> > 0xb7f02634 in calloc () from /lib/ld-linux.so.2
> > (gdb) bt
> > #0  0xb7f02634 in calloc () from /lib/ld-linux.so.2
> > #1  0xb7ef9110 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
> > #2  0xb7ef8b01 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
> > #3  0xb7e93200 in _dl_open () from /lib/tls/i686/cmov/libc.so.6
> > #4  0xb7efd43f in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
> > #5  0xb7e92c6f in _dl_open () from /lib/tls/i686/cmov/libc.so.6
> > #6  0xb7e9548d in __libc_dlsym () from /lib/tls/i686/cmov/libc.so.6
> > #7  0xb7efd43f in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
> > #8  0xb7e954ee in __libc_dlopen_mode ()
> > from /lib/tls/i686/cmov/libc.so.6
> > #9  0xb7ed7398 in pthread_cancel_init ()
> > from /lib/tls/i686/cmov/libpthread.so.0
> > #10 0xb7ed74c1 in _Unwind_ForcedUnwind ()
> > from /lib/tls/i686/cmov/libpthread.so.0
> > #11 0xb7ed51f1 in __pthread_unwind ()
> > from /lib/tls/i686/cmov/libpthread.so.0
> > #12 0xb7ed1210 in pthread_exit ()
> > from /lib/tls/i686/cmov/libpthread.so.0
> > #13 0xb7ec832a in rt_task_trampoline (cookie=0xbfcbb750)
> >    at /home/rpm/xenomai-2.2.4/src/skins/native/task.c:93
> > #14 0xb7ed0240 in start_thread ()
> > from /lib/tls/i686/cmov/libpthread.so.0
> > #15 0xb7e5e29e in clone () from /lib/tls/i686/cmov/libc.so.6
> > (gdb)
> > 
> > This means that the signal was sent as a result of performing a 
> > calloc()call, during the late binding of some dynamic library on 
> > behalf of
> > pthread_exit(), which gets called as your real-time task exits
> > immediately after the non-blocking call to rt_queue_read(). So 
> > this is
> > ok. The following patch should better illustrate the issue:
> > 
> > --- main.c~	2006-10-21 00:15:19.000000000 +0200
> > +++ main.c	2006-10-21 00:27:52.000000000 +0200
> > @@ -18,7 +18,7 @@
> >         some_data data;
> > 
> >         rt_queue_read( msq_q, &data, sizeof ( some_data ), 
> > TM_NONBLOCK);        
> > -        
> > +	rt_task_suspend(NULL);
> > }
> > 
> > void signal_handler(int sig)
> > 
> > PS: the call to rt_task_set_mode() in the main() function always 
> > fails,since the main routine is not a Xenomai-thread when started. 
> > Therefore,the call - which requires to be invoked by Xenomai 
> > threads - always
> > returns with -EPERM. Note: this behaviour may differ depending on the
> > skin bound to the application; for instance, the POSIX skin
> > automatically promotes the main code as a Xenomai-controlled 
> > thread, but
> > the native skin does not (maybe we should, though).
> > 
> > -- 
> > Philippe.
> > 
> > 
> > 
> 
-- 
Philippe.