Re: [Xenomai-help] MPC5200 OOPS time

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Daniel Schnell wrote:
> Hi,
> 
> 
> Gilles Chanteperdrix wrote:
> 
>>You should set the threads stack size with pthread_attr_setstacksize
>>(as other pthread_attr_set* functions, it should be used on a
>>previously initialized pthread_attr_t structure), ulimit -s only set
>>the stack size of the main thread, at least on some architectures.   
> 
> 
> pthread_attr_setstacksize() doesn't work for us. The system still does
> allocate the default linux stack size. Whereas ulimit -s sets the stack
> size for all created threads correctly.

pthread_attr_setstacksize does not work for the main thread, but works
for other threads on all architectures where I tested it, could you
check the return value ?

> 
> Can this confirm somebody with an mpc5200B based board (e.g. icecube,
> lite5200) ?
> 
> 
>>This is probably unrelated to the errors you see, but:
>>- passing the pthread_mutex_t by value is not supposed to work; once
>>a pthread_mutex_t is initialized with pthread_mutex_init, you should
>>pass the address of the very same pthread_mutex_t to other functions
>>of the API.  
> 
> 
> Hmm, this is mystique to me. pthread_mutex_t is a structure returned by
> value from within MutexCreate(). Passing structures back by value
> doesn't do harm to them. Also the pthread_mutex function seem to operate
> normally.

It works with Xenomai posix skin, because the structure simply holds a
pointer to the real structure used by the kernel, but this is so for
quite unobvious reasons (namely because sizeof(pthread_mutex_t) is to
small, and because it allows pthread_mutex_t to be shared between kernel
and user-space). But an implementation of the POSIX API could decide to
put the mutex lock count in the pthread_mutex_t structure, or to put the
pthread_mutex_t in a linked list, in these two cases, copying the
pthread_mutex_t would be wrong.


-- 
                                                 Gilles Chanteperdrix