From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <54F73E7A.2070100@xenomai.org> Date: Wed, 04 Mar 2015 18:18:50 +0100 From: Philippe Gerum MIME-Version: 1.0 References: <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> <54F716CC.1010600@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 04:26 PM, Helder Daniel wrote: > I reinstall xenomai enabling debug support: > > /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' '--enable-debug' > Looks good. > Then I removed all the code from the second process (binder.c), now > main() its empty. > > Running binder.c while creator.c is running, still gives a segmentation > fault. > > Since now there is no code in binder.c I compile it with no Xenomai > support, just gcc binder.c -o binder. > This way it runs (of course does nothing) without segmentation fault. > > So it must be something in the initialization of the Xenomai app. Ack. > And only happens when another Xenomai app (creator.c) is running. > In shared mode, it seems. > I did not backtrace it with gdbg yet, but I recompile it (main() still > empty) with Xenomai support and make an strace -f (while creator.c is > still running). gdb will pinpoint the exact location of this fault. > It seems that the segmentation fault happens when trying to lock memory > pages in RAM (called by the initialization code): > > [pid 3907] mlockall(MCL_CURRENT|MCL_FUTURE) = 0 > [pid 3907] --- SIGSEGV (Segmentation fault) @ 0 (0) --- > [pid 3908] +++ killed by SIGSEGV +++ > [pid 3909] +++ killed by SIGSEGV +++ strace only reports system calls, with mlockall returning a success status, so the segfault happens later. I'll build your test case and dig this issue tomorrow. Thanks for your patient reports, this will help fixing up the rough edges. -- Philippe.