Re: [Xenomai] posix skin pthread_create issue

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

On 09/17/2012 09:32 PM, Pierre Quelin wrote:

>>>>> After your answer, I try xenomai 2.6.1 and I increase the size of the
>>>>>    private stack pool from 128 to 2048 with the same result.
>>>>>
>>>>> Is there any limits for the number of threads in Xenomai ?
>>>> Not that I know of. There are only a few dynamic allocations in the
>>>> various pools you already mentioned. The corresponding options are:
>>>> XENO_OPT_REGISTRY_NRSLOTS (maximum number of objects in the registry,
>>>> each thread is registered in the registry)
>>>> XENO_OPT_SYS_HEAPSZ (system heap, used for various calls to xnmalloc)
>>>> XENO_OPT_SEM_HEAPSZ (semaphore heap, use for allocating 4 bytes per
>>>> thread + 4 bytes per mutex)
>>>>
>>>> But anyway, debugging the issue you have should be relatively easy by
>>>> adding printfs/printks, starting from src/skins/posix/thread.c (function
>>>> __wrap_pthread_create), continuing in ksrc/skins/posix/syscall.c,
>>>> function __pthread_create, etc...
>>> I try to obtain information about my context but all seems to be ok.
>>
>> You have to put a "pause" after the failing call to pthread_create,
>> because otherwise if calling exit, when the process fails, all the
>> memory it allocated in the various pools is freed.
> I found the problem. It seems that the private sem heap is to small.
> 
> I'm not sure about which parameter to increase in kernel menu so at 
> first I increase :


"private sem heap" -> "private semaphores heap", how can this not be clear?

> generation@emb:~$ cat /proc/xenomai/heap

> TOTAL USED PAGESZ NAME
> 118784 64 4096 global sem heap
> 2600960 287120 512 main heap
> 129536 0 512 stack pool
> *118784 13424 4096 private sem heap [5633]*
> 
> and now it works fine.
> But just to understand, could you explain to me how I can retrive the 
> value 118784 with the kernel parameters ?


see include/nucleus/heap.h

> ? Is calling pthread_set_mode_np (PTHREAD_WARNSW, 0) inhibits the rise 
> of the signal for a page fault?


Yes, it inhibits the rise of the signal for any cause of switch to
secondary mode. Quoting the documentation:

"PTHREAD_WARNSW, when set, cause the signal SIGXCPU to be sent to the
current thread, whenever it involontary switches to secondary mode;"

so, obviously, when clear, the SIGXCPU is NOT SENT to the current thread
whenever it involontary switches to secondary mode. What else did you
understand when reading this documentation ?

>>> When I switch between xenomai 2.6.0 to xenomai 2.6.1 It seems that an
>>> #include is missing in the include/xenomai/posix/stdio.h file for the
>>> new size_t type.
>>>
>>> #include_next <stdio.h>
>>>
>>> #ifndef STDIO_H
>>> #define STDIO_H
>>>
>>> #include <stdarg.h>
>>> *#include <unistd.h> /* size_t */*
>>
>> Thanks for reporting this issue.
>>
>> That is strange, given the fact that stdio.h defines fwrite for
>> instance, which uses size_t. Could you provide a small .c or .C file
>> which fails to compile?
>>
>> We are certainly not going to include unistd.h, which is a POSIX header,
>> in stdio.h, which is an ANSI header, more like stddef.h, but AFAIK,
>> stddef.h should already be included in the system stdio.h
>>
>>
> cf. pme.h / pme.cpp
> 
> In file included from /usr/include/wchar.h:37:0,
>                   from /usr/include/c++/4.6/cwchar:46,
>                   from /usr/include/c++/4.6/bits/postypes.h:42,
>                   from /usr/include/c++/4.6/bits/char_traits.h:42,
>                   from /usr/include/c++/4.6/string:42,
>                   from 
> /home/generation/workspace/Projects/Application.xenomai/Libraries/libpme/pme/pme.h:16,
>                   from 
> /home/generation/workspace/Projects/Application.xenomai/Libraries/libpme/pme/pme.cpp:14:
> /usr/include/xenomai/posix/stdio.h:30:1: erreur: ‘size_t’ does not name 
> a type


weird localization, it is an "erreur", but the rest of the error
messages are in english. Ok, will check. Thanks for posting the test cases.

-- 
                                                                Gilles.