[Xenomai] Heap binding error (EWOULDBLOCK)

Philippe Gerum rpm at xenomai.org
Wed Oct 18 18:40:33 CEST 2017


On 10/18/2017 11:55 AM, Roberto Finazzi wrote:
> Il giorno mer, 18/10/2017 alle 11.02 +0200, Philippe Gerum ha scritto:
>> On 10/18/2017 08:03 AM, Roberto Finazzi wrote:
>>> Hi,
>>> thank you for your answer, but there was already both --enable-registry
>>> and --enable-pshared as I can see using /usr/xenomai/sbin/version -a.
>>>
>>
>> Please paste the output of:
>> # <your-test-app> --dump-config.
>>
> 
> 
> based on Xenomai/cobalt v3.0.5
> CONFIG_MMU=1
> CONFIG_SMP=1
> CONFIG_XENO_BUILD_ARGS=" '--with-core=cobalt' '--disable-debug'
> '--enable-pshared' '--enable-smp' '--enable-registry'"
> CONFIG_XENO_BUILD_STRING="x86_64-unknown-linux-gnu"
> CONFIG_XENO_COBALT=1
> CONFIG_XENO_COMPILER="gcc version 6.3.0 20170516 (Debian 6.3.0-18) "
> CONFIG_XENO_DEFAULT_PERIOD=100000
> CONFIG_XENO_FORTIFY=1
> CONFIG_XENO_HOST_STRING="x86_64-unknown-linux-gnu"
> CONFIG_XENO_LORES_CLOCK_DISABLED=1
> CONFIG_XENO_PREFIX="/usr/xenomai"
> CONFIG_XENO_PSHARED=1
> CONFIG_XENO_RAW_CLOCK_ENABLED=1
> CONFIG_XENO_REGISTRY=1
> CONFIG_XENO_REGISTRY_ROOT="/var/run/xenomai"
> CONFIG_XENO_REVISION_LEVEL=5
> CONFIG_XENO_SANITY=1
> CONFIG_XENO_TLSF=1
> CONFIG_XENO_TLS_MODEL="initial-exec"
> CONFIG_XENO_UAPI_LEVEL=14
> CONFIG_XENO_VERSION_MAJOR=3
> CONFIG_XENO_VERSION_MINOR=0
> CONFIG_XENO_VERSION_NAME="Sisyphus's Boulder"
> CONFIG_XENO_VERSION_STRING="3.0.5"
> CONFIG_XENO_X86_VSYSCALL=1
> ---
> CONFIG_XENO_ASYNC_CANCEL is OFF
> CONFIG_XENO_COPPERPLATE_CLOCK_RESTRICTED is OFF
> CONFIG_XENO_DEBUG is OFF
> CONFIG_XENO_DEBUG_FULL is OFF
> CONFIG_XENO_LIBS_DLOPEN is OFF
> CONFIG_XENO_MERCURY is OFF
> CONFIG_XENO_VALGRIND_API is OFF
> CONFIG_XENO_WORKAROUND_CONDVAR_PI is OFF
> ---
> PTHREAD_STACK_DEFAULT=65536
> AUTOMATIC_BOOTSTRAP=1
> 
>>> Just to be sure for the code, this is the first program I used.
>>>
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>> #include <signal.h>
>>> #include <sys/mman.h>
>>> #include <alchemy/task.h>
>>> #include <alchemy/sem.h>
>>>
>>> RT_TASK task;
>>> RT_SEM semA;
>>>
>>> void end(int sig) {
>>>   rt_sem_delete(&semA);
>>
>> Calling rt_sem_delete() over a signal handler is unsafe.
>>
>>>   exit(0);
>>> }
>>>
>>> int main() {
>>> int err;
>>>
>>> signal (SIGINT, end);
>>>
>>> mlockall(MCL_CURRENT|MCL_FUTURE);
>>
>> Explicit mlock is redundant with Xenomai 3.x (libcobalt does this for
>> you during early init).
>>
> 
> Ok, thank you.
> 
>>> err=rt_task_shadow(&task, "writetest", 10, 0);
>>>
>>> err= rt_sem_create(&semA, "semA", 0, S_FIFO);
>>> printf("After create= %d\n", err);
>>>
>>> while(1) ;
>>>
>>
>> That infinite CPU-bound loop should rapidly cause a hard lockup, even on
>> a multi-core system.
>>
> 
> To simplify I removed part of source code not useful for understand the
> problem...
> 
>>> }
>>>
>>> And this is the second one.
>>>  
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>> #include <signal.h>
>>> #include <sys/mman.h>
>>> #include <alchemy/task.h>
>>> #include <alchemy/sem.h>
>>>
>>> RT_TASK task;
>>> RT_SEM semA;
>>>
>>> void end(int sig) {
>>>
>>>   rt_sem_unbind(&semA);
>>>   exit(0);
>>> }
>>>
>>> int main() {
>>> int err;
>>>
>>> signal (SIGINT, end);
>>>
>>> mlockall(MCL_CURRENT|MCL_FUTURE);
>>> err=rt_task_shadow(&task, "readtest", 10, 0);
>>>
>>> err= rt_sem_bind(&semA, "semA", TM_INFINITE);
>>> printf("After bind= %d\n", err);
>>>
>>> while(1) ;
>>>
>>> }
>>>
>>> I started the first one and the semaphore was created without problems.
>>> When I started the second, it remained blocked on the rt_sem_bind.
>>>
>>
>> Are you starting both apps in sequence on a single shell command line,
>> like "./sem_create_app; ./sem_bind_app"?
>>
> 
> I started them in two different xterm. I tried also with one shell
> command line with the same result.
> 

You need to have both processes belong to the same session:
http://xenomai.org/2015/05/application-setup-and-init/#Standard_Xenomai_command_line_options

e.g.
# ./app1 --session=foo
# ./app2 --session=foo

Common session names for processes cause resources to be shared between
them. Otherwise, the binder expects the semaphore to be created in its
own private scope, which never happens.

And yes, the doc is terse regarding this and many other things, this is
hardly well explained, if ever explained at all.

-- 
Philippe.



More information about the Xenomai mailing list