Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: >> Gilles Chanteperdrix wrote: >>> Wolfgang Grandegger wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Wolfgang Grandegger wrote: >>>>>> Running under gdb shows: >>>>>> >>>>>> Program received signal SIGSEGV, Segmentation fault. >>>>>> [Switching to Thread 0x4885d4b0 (LWP 1127)] >>>>>> 0x0ff49100 in pthread_cancel () from /lib/libpthread.so.0 >>>>>> (gdb) where >>>>>> #0 0x0ff49100 in pthread_cancel () from /lib/libpthread.so.0 >>>>>> #1 0x10001d64 in ctrl_func (parm=0x0) at cancel-test.c:104 >>>>>> #2 0x0ffa98e4 in __pthread_trampoline () >>>>>> from /home/wolf/xenomai/lib/libpthread_rt.so.1 >>>>>> #3 0x0ff42a6c in start_thread () from /lib/libpthread.so.0 >>>>>> #4 0x0fdd18a0 in clone () from /lib/libc.so.6 >>>>>> Backtrace stopped: previous frame inner to this frame (corrupt stack?) >>>>>> >>>>>> Is pthread_cancel used from the Linux pthread library? And >>>>>> pthread_testcancel() as well? >>>>> Yes, and I guess, as you said, that it happens because calc_func is dead >>>>> when you try and cancel it. >>>> Yep, but it should not crash. >>> The spec says: >>> The pthread_cancel() function may fail if: >>> >>> [ESRCH] >>> No thread could be found corresponding to that specified by the >>> given thread ID. >>> >>> >>> So, it is a "may", returning ESRCH, as Xenomai does in kernel-space, is >>> not mandatory. >> I also got the return value ESRCH in another test. Nevertheless, a crash >> is not the expected behaviour, to say the least. Here pthread_cancel() >> obvoiusly get's interrupted and the calc_thread continues. Is it >> possible that pthread_cancel() switches to secondary mode? > > pthread_cancel switches to secondary mode if it has to send a signal (if > cancellation is in asynchronous mode, this happens when the target > thread is blocked inside a blocking call). But this should not be a > problem with RPI.
I disabled priority coupling in the kernel and it did not help or harm. This test uses PTHREAD_CANCEL_DEFERRED, which is also the default, if I understood correctly. > But the problem you should focus on is why the scheduler does not let > pthread_cancel run earlier. Don't know what you mean. The calc_func gets preempted and the ctrl_func calls pthread_cancel as expected... calc_func: at count 20 calc_func: at count 21 calc_func: at count 22 ctrl_func: cancel at count 23 ^^^^^^^^^ calc_func: at count 23 But then it stops somehow in pthread_cancel and calc_func continues to run. Wolfgang. _______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
