[Xenomai] Xenomai 2.6.4 segfault before main()

[Xenomai] Xenomai 2.6.4 segfault before main()

[Marco Barbosa]

Hi all,

while trying to build a xenomai app in a x86_64 debian 8.1 system I
was getting segfaults before the program even gets into main(). After
fiddling with this a bit, I built a minimal example which is really
minimal.

Program is:

$ cat main.cpp

int
main (int argn, char**argv)
{
  return 0;
}

Which is compiled with the command:

g++ -L/usr/xenomai/lib -ggdb main.cpp -o main_xen -lxenomai -lpthread_rt

Now by running the program, I get:

$ ./main_xen
Segmentation fault

Debugging with GDB gives this backtrace:

$ gdb ./main_xen
[... snip ...]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7ff5700 (LWP 9389)]
pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:134
134     ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No
such file or directory.
(gdb) bt
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:134
#1  0x00007ffff7bd945f in printer_loop () from /usr/xenomai/lib/libxenomai.so.0
#2  0x00007ffff6be90a4 in start_thread (arg=0x7ffff7ff5700) at
pthread_create.c:309
#3  0x00007ffff6ee404d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Now if this is not weird enough, I just found out that if I reverse
the order of those two libraries, i.e.:

g++ -L/usr/xenomai/lib -ggdb main.cpp -o main_xen -lpthread_rt -lxenomai

I will get no segfault in this situation, the program exits fine.

Does anyone have any idea of what is going on here? I would suspect
that by switching library order, initialization of some static data
which is done before entering main() is somehow affected and that can
result in segfault if done in the wrong order.

Of course, this is a very simple example and I seem to have found a
way around the problem, but in a more complex application with
makefiles generated by CMake, I really have little control over the
order in which libraries are declared and I am getting these segfaults
all the time.

Background info:
xenomai 2.6.4
debian 8.1
kernel 3.18.12
x86_64 platform (Core i5)

Best,
Marco Barbosa

Re: [Xenomai] Xenomai 2.6.4 segfault before main()

[Gilles Chanteperdrix]

On Thu, Aug 20, 2015 at 04:58:39PM +0100, Marco Barbosa wrote:
> Hi all,
> 
> while trying to build a xenomai app in a x86_64 debian 8.1 system I
> was getting segfaults before the program even gets into main(). After
> fiddling with this a bit, I built a minimal example which is really
> minimal.
> 
> Program is:
> 
> $ cat main.cpp
> 
> int
> main (int argn, char**argv)
> {
>   return 0;
> }
> 
> Which is compiled with the command:
> 
> g++ -L/usr/xenomai/lib -ggdb main.cpp -o main_xen -lxenomai -lpthread_rt
> 
> Now by running the program, I get:
> 
> $ ./main_xen
> Segmentation fault
> 
> Debugging with GDB gives this backtrace:
> 
> $ gdb ./main_xen
> [... snip ...]
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ffff7ff5700 (LWP 9389)]
> pthread_cond_wait@@GLIBC_2.3.2 () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:134
> 134     ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No
> such file or directory.
> (gdb) bt
> #0  pthread_cond_wait@@GLIBC_2.3.2 () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:134
> #1  0x00007ffff7bd945f in printer_loop () from /usr/xenomai/lib/libxenomai.so.0
> #2  0x00007ffff6be90a4 in start_thread (arg=0x7ffff7ff5700) at
> pthread_create.c:309
> #3  0x00007ffff6ee404d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> 
> Now if this is not weird enough, I just found out that if I reverse
> the order of those two libraries, i.e.:
> 
> g++ -L/usr/xenomai/lib -ggdb main.cpp -o main_xen -lpthread_rt -lxenomai
> 
> I will get no segfault in this situation, the program exits fine.
> 
> Does anyone have any idea of what is going on here? I would suspect
> that by switching library order, initialization of some static data
> which is done before entering main() is somehow affected and that can
> result in segfault if done in the wrong order.
> 
> Of course, this is a very simple example and I seem to have found a
> way around the problem, but in a more complex application with
> makefiles generated by CMake, I really have little control over the
> order in which libraries are declared and I am getting these segfaults
> all the time.

A makefile, whether cmake or make should use xeno-config to get the
libraries. And xeno-config puts -lxenomai last. I believe. So,
this is a non issue, unless you do things which the documentation
tells you not to do.

-- 
					    Gilles.
https://click-hack.org