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>]

ok.
Here is the backtrace of "binder" process with gdb:

root@debian:~/xenomaiRegistryCheck# gdb binder
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/xenomaiRegistryCheck/binder...done.
(gdb) r
Starting program: /root/xenomaiRegistryCheck/binder
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
[New Thread 0xb7fdeb70 (LWP 4409)]
[New Thread 0xb7cb5b70 (LWP 4410)]

Program received signal SIGSEGV, Segmentation fault.
0xb76cdc10 in ?? ()
(gdb) bt
#0  0xb76cdc10 in ?? ()
#1  0xb7fafa29 in hash_search (t=0xb7cd9110, key=key@entry=0xb7fca217,
len=12)
    at hash.c:193
#2  0xb7fa5015 in cluster_init (c=c@entry=0xb7fcddfc,
    name=name@entry=0xb7fca217 "alchemy.task") at cluster.c:118
#3  0xb7fa526a in syncluster_init (sc=0xb7fcddfc,
    name=name@entry=0xb7fca217 "alchemy.task") at cluster.c:214
#4  0xb7fc25c9 in alchemy_init () at init.c:102
#5  0xb7fa6ea3 in copperplate_init (argcp=argcp@entry=0xbffffc10,
    argvp=argvp@entry=0xbffffc14) at init.c:635
#6  0xb7fa75d3 in copperplate_main (argc=1, argv=0xbffffcb4) at main.c:27
#7  0xb7df8e46 in __libc_start_main ()
   from /lib/i386-linux-gnu/i686/cmov/libc.so.6
#8  0x080484f1 in _start ()
(gdb)




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

> 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.
>



-- 
Helder Daniel
UALG - FCT
DEEI

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