From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <54F716CC.1010600@xenomai.org> Date: Wed, 04 Mar 2015 15:29:32 +0100 From: Philippe Gerum MIME-Version: 1.0 References: <54F5BE3F.4010008@xenomai.org> <54F5C020.8090102@xenomai.org> <54F5CD4D.8080004@xenomai.org> <54F5D6C6.40908@xenomai.org> <54F5E958.2090701@xenomai.org> <54F5EA06.4040104@xenomai.org> <54F60A62.3020708@xenomai.org> <54F60C16.5070500@xenomai.org> <54F614EF.7040307@xenomai.org> <54F6C50F.5040301@xenomai.org> <54F6EF2E.1090705@xenomai.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] Xenomai/cobalt: low_init(): binding failed: Function not implemented error issued when trting to run latency app on xeno 3.x-rc3 List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Helder Daniel Cc: "Xenomai@xenomai.org" On 03/04/2015 03:25 PM, Helder Daniel wrote: > 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. > In case of a segfault, run the application over gdb, so that you can provide the backtrace. Building with --enable-debug will help. > /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 > 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 -- Philippe.