Re: [Xenomai] posix skin pthread_create issue

Re: [Xenomai] posix skin pthread_create issue

[Gilles Chanteperdrix]

On 09/12/2012 09:26 PM, Pierre Quelin wrote:

> Thank you for quick answer.
> 
> my context
> 
> xenomai : 2.6.0 adeos : 2.11-02 kernel : 2.6.38.8 arch : pentium pro 
> gcc : 4.6.3 distro : Ubuntu 12.04


If you use this version, add "-fno-omit-frame-pointer" to the CFLAGS
passed to the configure script.

> 
> I already read the TROUBLESHOOTING guide but I don't understand all
> the informations contained in //proc/<pid>/maps/. I already try
> "ulimit -s 81920" without success.


You usually want to decrease ulimit -s, not increase it.

> 
> 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 don't know if there is the link with my problem but I have some 
> strange things.
> 
> With Xenomai 2.6.1, when I launch the latency/switch test I obtain
> some negative values like -1.03µs.


That is a known issue. See for instance:
http://www.blaess.fr/christophe/2012/07/23/les-latences-de-xenomai/


 After mlockall() in
> //proc/xenomai/faults/ I obtain 2 or more Page fault without visible
> software effects. I can't locate it. If you could help me.


> 
> Our application is writting in C++. At the begining it initialise a
> lot of static objects as mutex and do a lot of allocation/syscall. So
> it do a lot of switch in secondary mode. To solve this, at first, I
> just catch the SIGXCPU in a static class..


Well, you should be able to catch the page faults with SIGXCPU, but you
have to ensure that pthread_set_mode and the signal handler installation
are done before the static objects constructors. And of course, you have
to ensure that Xenomai libpthread_rt library constructor gets run before
your static initializers. That is a problem with C++. Also note that
PTHREAD_MUTEX_INITIALIZER and PTHREAD_COND_INITIALIZER do not work with
Xenomai posix skin.

> 
> 
> Sorry for messages at the end of the mail but I can't remove it
> (!?.§§!! Lotus N..es and security policy) Could you please send me a
> copy of your answer to pierre.quelin@solystic.com


The free.fr address is fine.


-- 
                                                                Gilles.

Re: [Xenomai] posix skin pthread_create issue

[Gilles Chanteperdrix]

On 09/13/2012 07:13 PM, Pierre Quelin wrote:

> 
> Le 12/09/2012 22:27, Gilles Chanteperdrix a écrit :
>> On 09/12/2012 09:26 PM, Pierre Quelin wrote:
>>
>>> Thank you for quick answer.
>>>
>>> my context
>>>
>>> xenomai : 2.6.0 adeos : 2.11-02 kernel : 2.6.38.8 arch : pentium pro
>>> gcc : 4.6.3 distro : Ubuntu 12.04
>>
>> If you use this version, add "-fno-omit-frame-pointer" to the CFLAGS
>> passed to the configure script.
> I have tryed this with xenomai 2.6.0 and 2.6.1 without success. Maybe an 
> incompatible option in my CMakeLists file.
> ...
> ELSEIF ($ENV{SOLYSTIC_BUILD_TARGET} STREQUAL "linux-x86")
>     SET(CMAKE_C_FLAGS "-O0 -g3 -mtune=pentium -march=pentium -ansi 
> -fno-builtin -fno-defer-pop -Wall -finput-charset=iso-8859-1 
> -fexec-charset=iso-8859-1")
>     SET(CMAKE_CXX_FLAGS "-O0 -g3 -mtune=pentium -march=pentium -ansi 
> -fno-builtin -fno-defer-pop -Wall -Wreorder -finput-charset=iso-8859-1 
> -fexec-charset=iso-8859-1")
> ELSEIF ($ENV{SOLYSTIC_BUILD_TARGET} STREQUAL "xenomai-x86")
>      EXECUTE_PROCESS(COMMAND xeno-config --skin posix --cflags 
> OUTPUT_VARIABLE XENO_POSIX_CFLAGS OUTPUT_STRIP_TRAILING_WHITESPACE)
>      SET(CMAKE_C_FLAGS "${XENO_POSIX_CFLAGS} -O0 -g3 -mtune=pentium 
> -march=pentium -ansi *-fno-omit-frame-pointer* -fno-builtin 
> -fno-defer-pop -Wall -finput-charset=iso-8859-1 -fexec-charset=iso-8859-1")
>      SET(CMAKE_CXX_FLAGS "${XENO_POSIX_CFLAGS} -O0 -g3 -mtune=pentium 
> -march=pentium -ansi *-fno-omit-frame-pointer* -fno-builtin 
> -fno-defer-pop -Wall -Wreorder -finput-charset=iso-8859-1 
> -fexec-charset=iso-8859-1")
> ...


If you have a compilation issue, you will know it, because the syscall
in __wrap_pthread_create will not return the same value as the value
printed in __pthread_create in kernel space, or the arguments received
in kernel space will not be the same as the ones you pass in user-space.
So, printf/printk is the way to go. Anyway, I am talking about the
CFLAGS of the Xenomai library, the one passed to Xenomai configure
script. Not the CFLAGS of your application. As I said, you should not
need this with Xenomai 2.6.1.

>>> 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.

>>   After mlockall() in
>>> //proc/xenomai/faults/ I obtain 2 or more Page fault without visible
>>> software effects. I can't locate it. If you could help me.
>>>
>>>
>>> Our application is writting in C++. At the begining it initialise a
>>> lot of static objects as mutex and do a lot of allocation/syscall. So
>>> it do a lot of switch in secondary mode. To solve this, at first, I
>>> just catch the SIGXCPU in a static class..
>>
>> Well, you should be able to catch the page faults with SIGXCPU, but you
>> have to ensure that pthread_set_mode and the signal handler installation
>> are done before the static objects constructors. And of course, you have
>> to ensure that Xenomai libpthread_rt library constructor gets run before
>> your static initializers. That is a problem with C++. Also note that
>> PTHREAD_MUTEX_INITIALIZER and PTHREAD_COND_INITIALIZER do not work with
>> Xenomai posix skin.
> I watch this problem for the first time when I try to resolve the 
> pthread_create() error.
> The problem, there is a lot of SIGXCPU generated by the switch between 
> rt and linux domain that mask the page fault in a lot of noise.
> I tried to disable everything with pthread_set_mode_np(PTHREAD_WARNSW, 
> 0) in all the thread context (body) but I don't understand why, it still 
> remains.


Not all SIGXCPU are due to page faults. There are various reasons for
SIGXCPU, for an example of how to know for which reason you receive the
signal, see examples/sigdebug.c in xenomai sources.

> 
> I know that the application is not real time with the domain switch but 
> at first how can I disable the SIGXCPU in every context to solve this 
> page fault ?
> 
> You say that I have to be sure that Xenomai libpthread_rt library 
> constructor gets run before our static initializers, but how to do that ?


Well, the static objects constructors order is a general C++ problem
which goes well beyond the context of Xenomai. See:
http://www.parashift.com/c++-faq-lite/static-init-order.html
The short story is: don't use static objects with constructors.

> 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


-- 
                                                                Gilles.

Re: [Xenomai] posix skin pthread_create issue

[Gilles Chanteperdrix]

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.

Re: [Xenomai] posix skin pthread_create issue

[Gilles Chanteperdrix]

On 09/17/2012 10:46 PM, Pierre Quelin wrote:

> 
> Le 17/09/2012 21:50, Gilles Chanteperdrix a écrit :
>> 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?
> This link is clear, but I don't understand the link between "private 
> semaphores heap", "global semaphores heap" and "system heap" ?
> I just try to fix the right values for my context and my application.


There is no link between the various heaps, which is the reason why they
have separate configuration options. Now if the question is to know how
much space in each heap consumes a thread, a mutex, etc... I guess
nobody ever did the computation. For the semaphore heaps at least it is
clear: each thread consumes 4 bytes in the semaphore heap, each mutex
consumes 4 bytes in the private or global heap depending on whether it
is a process-private, or global mutex (for posix mutexes, this is
related to pthread_mutexattr_setpshared).

>>> ? 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 ?
> 
> I don't understand that a page fault is 'just' a switch to secondary mode.


A switch to secondary mode is devastating for a real-time thread running
in primary mode.
A page fault causes a switch to secondary mode so that the Linux kernel
can handle the page fault, the only alternative is probably crashing, or
suspending the thread that had the fault. SIGXCPU is sent, if you
enabled the PTHREAD_WARNSW bit.

So, PTHREAD_WARNSW should be armed for threads which should stay in
primary mode. The critical ones.

Anyway, it is not really normal to have page faults, using mlockall and
the disabling of on-demand mappings by the I-pipe patch should prevent
page faults from happening. So, it would be interesting to know what
cause these faults.

> Before posting a message on this mailing list I tried to read all 
> documents on Xenomaiand solve the problem by myself.
> Maybe I did not read the right papers or I did not understand what I 
> have read and I apologize.


No need to apologize, the mailing list is here so that people can ask
questions. I guess there are more answers (maybe not the good ones) in
the mailing list archives than in the documentation.

Regards.

-- 
                                                                Gilles.

Re: [Xenomai] posix skin pthread_create issue

[Gilles Chanteperdrix]

On 09/17/2012 11:02 PM, Gilles Chanteperdrix wrote:

> On 09/17/2012 10:46 PM, Pierre Quelin wrote:
> 
>>
>> Le 17/09/2012 21:50, Gilles Chanteperdrix a écrit :
>>> 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?
>> This link is clear, but I don't understand the link between "private 
>> semaphores heap", "global semaphores heap" and "system heap" ?
>> I just try to fix the right values for my context and my application.
> 
> 
> There is no link between the various heaps, which is the reason why they
> have separate configuration options. Now if the question is to know how
> much space in each heap consumes a thread, a mutex, etc... I guess
> nobody ever did the computation. For the semaphore heaps at least it is
> clear: each thread consumes 4 bytes in the semaphore heap, each mutex
> consumes 4 bytes in the private or global heap depending on whether it
> is a process-private, or global mutex (for posix mutexes, this is
> related to pthread_mutexattr_setpshared).
> 
>>>> ? 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 ?
>>
>> I don't understand that a page fault is 'just' a switch to secondary mode.
> 
> 
> A switch to secondary mode is devastating for a real-time thread running
> in primary mode.
> A page fault causes a switch to secondary mode so that the Linux kernel
> can handle the page fault, the only alternative is probably crashing, or
> suspending the thread that had the fault. SIGXCPU is sent, if you
> enabled the PTHREAD_WARNSW bit.
> 
> So, PTHREAD_WARNSW should be armed for threads which should stay in
> primary mode. The critical ones.
> 
> Anyway, it is not really normal to have page faults, using mlockall and
> the disabling of on-demand mappings by the I-pipe patch should prevent
> page faults from happening. So, it would be interesting to know what
> cause these faults.


Again, due to the C++ static objects constructors "feature", it may 
simply be that you start using Xenomai before the call to mlockall, and 
you simply somehow fail to see the signal sent by Xenomai, because it 
is also SIGXCPU and the handler you installed does not check the reason 
sent by Xenomai, for instance, the following commit, fixes exactly this 
issue for the latency test:

http://git.xenomai.org/?p=xenomai-2.6.git;a=commitdiff;h=d8c2bccce5de41a4b183c9a140dc12b0a2606261;hp=9afc3bce3770089083fa5d1bca596b53f5c7d058

-- 
                                                                Gilles.

[Xenomai] posix skin pthread_create issue

[Pierre.QUELIN]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=US-ASCII, Size: 2306 bytes --]


Dear all,

I have an application that is working fine with the standard Linux kernel
API and don't works if I build it with Xenomai API.

I have a strange issue. At the begining, the application creates 28 threads
and all the 33 next returns an error. pthread_create() returns 12 (ENOMEM).

I'm not sure to understand which memory is missing.

To solve this I have try :

1) to fix the pthread stack size at PTHREAD_STACK_MIN.
=>without effect

2) to change the RealTime sub-system options
I increase the number of registry slots from 512 to 1024
I increase the size of the system heap from 256 to 1024
I increase the size of the private stack pool from 128 to 512
=>without effect

Could you please help me.

Best regards

Pierre Quelin
Ce message et toutes les pièces jointes (ci-après le "Message") sont confidentiels et établis à l'intention exclusive de leurs destinataires. Si vous avez reçu le Message par erreur, merci de l'indiquer à son expéditeur par retour et de procéder à sa destruction dans vos systèmes.Toute utilisation ou diffusion de son contenu non autorisée est strictement interdite. Tout message électronique est susceptible d'altération. SOLYSTIC décline toute responsabilité au titre du Message s'il a été altéré, déformé ou falsifié. SOLYSTIC ne saurait être tenue pour responsable, ni de la transmission erronée ou incomplète des informations contenues dans ce message, ni des délais de réception ou des dommages causés à votre système. SOLYSTIC ne garantit, ni que l'intégrité de la communication ait été maintenue, ni que cette transmission est exempte de virus, d'interceptions ou d'interférences.

This message and any attachments (the "Message") are confidential and intended solely for the addressee(s). Any unauthorised use or dissemination of the Message is strictly prohibited. E-mails are susceptible to alteration. SOLYSTIC shall not be liable for the Message if altered, changed or falsified. SOLYSTIC shall not be liable for the improper or incomplete transmission of the information contained in the Message nor for any delay in its receipt or damage to your system. SOLYSTIC does neither guarantee that the integrity of the Message has been maintained, nor that this communication is free of viruses, interceptions or interferences.

Re: [Xenomai] posix skin pthread_create issue

[Gilles Chanteperdrix]

On 09/12/2012 10:19 AM, Pierre.QUELIN@solystic.com wrote:
> 
> Dear all,
> 
> I have an application that is working fine with the standard Linux
> kernel API and don't works if I build it with Xenomai API.

What version of Xenomai? What I-pipe patch? What platform?

> 
> I have a strange issue. At the begining, the application creates 28
> threads and all the 33 next returns an error. pthread_create()
> returns 12 (ENOMEM).
> 
> I'm not sure to understand which memory is missing.
> 
> To solve this I have try :
> 
> 1) to fix the pthread stack size at PTHREAD_STACK_MIN. =>without
> effect

For the stack size issue, see:
http://www.xenomai.org/documentation/xenomai-2.6/html/TROUBLESHOOTING/#_my_application_reserves_a_lot_of_memory

But that is probably not your issue.

> 2) to change the RealTime sub-system options I increase the number of
> registry slots from 512 to 1024 I increase the size of the system
> heap from 256 to 1024 I increase the size of the private stack pool
> from 128 to 512 =>without effect
> 
> Could you please help me.

ENOMEM seems to be returned in case the stack pool is not large enough.
Maybe 512 is not enough? If using Xenomai 2.6.0 with gcc 4.7, you should
add '-fno-omit-frame-pointer' to the CFLAGS. This issue is fixed in
Xenomai 2.6.1.

> 
> Best regards
> 
> Pierre Quelin Ce message et toutes les pièces jointes (ci-après le
> "Message") sont confidentiels et établis à l'intention exclusive de
> leurs destinataires. Si vous avez reçu le Message par erreur, merci
> de l'indiquer à son expéditeur par retour et de procéder à sa
> destruction dans vos systèmes.Toute utilisation ou diffusion de son
> contenu non autorisée est strictement interdite. Tout message
> électronique est susceptible d'altération. SOLYSTIC décline toute
> responsabilité au titre du Message s'il a été altéré, déformé ou
> falsifié. SOLYSTIC ne saurait être tenue pour responsable, ni de la
> transmission erronée ou incomplète des informations contenues dans ce
> message, ni des délais de réception ou des dommages causés à votre
> système. SOLYSTIC ne garantit, ni que l'intégrité de la communication
> ait été maintenue, ni que cette transmission est exempte de virus,
> d'interceptions ou d'interférences.
> 
> This message and any attachments (the "Message") are confidential and
> intended solely for the addressee(s). Any unauthorised use or
> dissemination of the Message is strictly prohibited. E-mails are
> susceptible to alteration. SOLYSTIC shall not be liable for the
> Message if altered, changed or falsified. SOLYSTIC shall not be
> liable for the improper or incomplete transmission of the information
> contained in the Message nor for any delay in its receipt or damage
> to your system. SOLYSTIC does neither guarantee that the integrity of
> the Message has been maintained, nor that this communication is free
> of viruses, interceptions or interferences.

As usual, please send us messages without this notice: the only way for
us to comply with this notice is to unsubscribe you from the mailing
list. The mailing list is public, its archives are on the web for all to
see, so we are actively disseminating your message.

-- 
					    Gilles.