[Xenomai] Heap binding error (EWOULDBLOCK)

Roberto Finazzi rfinaz at tin.it
Wed Oct 18 11:55:51 CEST 2017


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.

Regards
Roberto




More information about the Xenomai mailing list