Re: [Xenomai-help] pthread cancelation and scheduling magics

[Wolfgang Grandegger <wg@domain.hid>]

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?

Wolfgang.