From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Thu, 20 Aug 2015 18:33:00 +0200
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Message-ID: <20150820163300.GA3701@hermes.click-hack.org>
References: <CACwQX5PgaPA47Ak3gbNfSGJtAYhusP0QC4ZwNSSfd8_Y1wTRjA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACwQX5PgaPA47Ak3gbNfSGJtAYhusP0QC4ZwNSSfd8_Y1wTRjA@mail.gmail.com>
Subject: Re: [Xenomai] Xenomai 2.6.4 segfault before main()
List-Id: Discussions about the Xenomai project <xenomai.xenomai.org>
List-Unsubscribe: <http://xenomai.org/mailman/options/xenomai>,
 <mailto:xenomai-request@xenomai.org?subject=unsubscribe>
List-Archive: <http://xenomai.org/pipermail/xenomai/>
List-Post: <mailto:xenomai@xenomai.org>
List-Help: <mailto:xenomai-request@xenomai.org?subject=help>
List-Subscribe: <http://xenomai.org/mailman/listinfo/xenomai>,
 <mailto:xenomai-request@xenomai.org?subject=subscribe>
To: Marco Barbosa <marcoafbarbosa@gmail.com>
Cc: xenomai@xenomai.org

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