Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3

[Helder Daniel <hdaniel@ualg.pt>]

I reinstalled xenomai with pshared enabled but it still do not work.
Second process gives now a segmentation fault when trying to bind.
If executed with --no-registry (it will not bind of course) but it does not
segment fault also.

/usr/xenomai/sbin/version -a
Xenomai/mercury v3.0-rc3 --
Target: i686-pc-linux-gnu
Compiler: gcc version 4.7.2 (Debian 4.7.2-5)
Build args:  '--with-core=mercury' '--enable-registry' '--enable-pshared'
'--prefix=/usr/xenomai'


On 4 March 2015 at 11:40, Philippe Gerum <rpm@xenomai.org> wrote:

> On 03/04/2015 12:21 PM, Helder Daniel wrote:
> > Ok.
> > This way I can recover registry.
> > I did not find yet when and why registry crashes.
> > If I found the scenario I'll report it.
> >
> > Meanwhile I am having roubles binding to a semaphore created in one
> > process, from another process.
> > I used a simple demo app to show what is happening (full source code
> > attached)
> >
> > From one process (creator.c) a semaphore is created and binded by its
> > registry name "namedSem":
> >
> > rt_task_shadow (&task, "creatorTask", 20, 0);
> > rt_sem_create(&sem, "namedSem", 0, S_FIFO);
> > rt_sem_bind(&sem, "namedSem", TM_INFINITE);
> > for (;;) sleep (100);
> >
> > So all ok here.
> >
> > Now keeping creator.c running in an xterm and trying to bind to this
> > semaphore from another process (binder.c), from another xterm, it does
> > not work:
> >
> > rt_task_shadow (&task, "binderTask", 20, 0);
> > rt_sem_bind(&sem, "namedSem", TM_INFINITE);
> >
> > rt_sem_bind() never binds to the semaphore "namedSem".
> > It seams it does not find it.
> > If a timeout is set:
> >
> > err=rt_sem_bind(&sem, "namedSem", TM_INFINITE);
> >
> > it returns with error -110 (ETIMEDOUT)
> >
> > But the semaphore exists in registry:
> >
> > $> cat /var/run/xenomai/anon/4267/alchemy/semaphores/namedSem
> > =0
> >
> > I think on version 2.5.x a named object is global to the system.
> > So when creating a semaphore named "namedSem" by a process it is visible
> > for all other processes.
> >
> > Maybe in 3.x semaphores (and other objects) are local to processes?
> > Since they are stored in the registry under the pid of the creator
> process?
>
> With 3.x, --enable-pshared must be passed to enable object sharing
> between processes. The actual registry is not maintained in kernel space
> anymore, so the support libraries have to know whether they should
> maintain it.
>
> --
> Philippe.
>



-- 
Helder Daniel
UALG - FCT
DEEI

http://w3.ualg.pt/~hdaniel