From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 20 Oct 2006 17:37:52 -0600 From: Sunny Bhuller Subject: Re: [Xenomai-help] rt_queue_read switch to secondary mode Message-id: <20fca7920fc595.20fc59520fca79@domain.hid> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7bit Content-disposition: inline Reply-To: sbhuller@domain.hid List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rpm@xenomai.org Cc: xenomai@xenomai.org 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 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. > > >