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 <[EMAIL PROTECTED]>
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.
>
>
>
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
