Hi Jim, Kaijen,
I haven't heard of anyone using yarp with xenomai. I'll be very
interested to hear how it goes for you :-).
I suggest you check first that YARP is passing its own regression tests:
If there are any failures, let me know and I can help you pinpoint the
problem that way. But it sounds like the problem is a bit more complex,
in that it shows up specifically when you have a "link to an application
using xenomai", so the regression tests probably won't help. Always
good to be sure though.
You can always get a bit more debugging information from any program
using yarp by setting YARP_VERBOSE=1 in the environment.
From your stack trace, it looks like the problem is occurring in one of
the open() methods in src/libYARP_OS/src/SocketTwoWayStream.cpp (after
that, it is down into ACE) -- probably when the main listener socket
associated with the port is starting up (it has a unique thread
associated with it). You could try debugging in there a little bit. It
sounds like at least some socket operations are working if you're seeing
communication with the yarp server.
Can you explain the setup in a bit more detail? What is the nature of a
link to an application using xenomai?
Huan Liu wrote:
> Hi Paul,
> Thanks! Your 'last resort' solution solved our problem. We
> successfully compiled yarp 2.2.0.
> You are right. We were using an old version of ACE, and I think I
> messed up when I tried to upgrade ACE.
> But unfortunately, the new yarp still doesn't fix the problem we were
> having earlier that led us to upgrade yarp.
> We are trying to run some applications using xenomai, a realtime
> kernel patch for linux. But we can't open a yarp port whenever there
> is a link to an application using xenomai. We always get a seg fault
> when we try to open a yarp port. We can see the port being opened in
> the yarp server, but it crashes when it's trying to create a new
> thread using clone. Here's the gdb trace:
> yarp: Port /in active at tcp://220.127.116.11:10042
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1211532400 (LWP 8563)]
> 0x081dcd3c in accept ()
> (gdb) where
> #0 0x081dcd3c in accept ()
> #1 0x0812121f in ACE_OS::accept ()
> #2 0x08121013 in ACE_SOCK_Acceptor::accept ()
> #3 0x081365d7 in yarp::SocketTwoWayStream::open ()
> #4 0x08136965 in yarp::TcpFace::read ()
> #5 0x0811a187 in yarp::PortCore::run ()
> #6 0x080e7be8 in theExecutiveBranch ()
> #7 0x0816c8a0 in ACE_OS_Thread_Adapter::invoke ()
> #8 0x081361f6 in ace_thread_adapter ()
> #9 0xb7f0331b in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
> #10 0xb7d6b57e in clone () from /lib/tls/i686/cmov/libc.so.6
> Have you seen anything like this before? Or do you know anyone who's
> successfully used yarp with xenomai? Super thanks for your help!
> Jim and Kaijen
> Paul Fitzpatrick wrote:
>> Huan Liu wrote:
>>> I keep getting the following error:
>>> [ 73%] Building CXX object
>>> Linking CXX executable ../../bin/harness_os
>>> CMakeFiles/harness_os.dir/harness/AddressTest.o: In function
>>> `ACE_OS::memcpy(void*, void const*, unsigned int)':
>>> void const*, unsigned int)]+0x1b): undefined reference to
>>> `ACE_OS::fast_memcpy(void*, void const*, unsigned int)'
>>> collect2: ld returned 1 exit status
>>> make: *** [bin/harness_os] Error 1
>>> make: *** [src/libYARP_OS/CMakeFiles/harness_os.dir/all] Error 2
>>> make: *** [all] Error 2
>>> Does anyone know how to fix this? I'm using ACE 5.6. Thanks a lot!
>> Hi Jim,
>> What OS/distribution are you compiling on?
>> This sounds like a mismatch between the compiler flags used to
>> compile ACE and those used to compile YARP. If you've changed ACE
>> version on your machine, make sure that the header files and library
>> files are in synch, and that you've done a "make clean" for YARP.
>> Do "make VERBOSE=1" to see all the compiler flags being set while
>> compiling YARP. Compare this with settings used to compile ACE. I'd
>> watch out particularly for flags controlling inlining.
>> If you can't make any progress, there is a method of last resort that
>> might work. You can download a version of ACE configured specially
>> for YARP (and stripped of everything YARP does not use) here:
>> (take the most recent ace4yarp-5.6.*.tar.gz)
>> You can unpack that, overlay the directories on the YARP source tree,
>> and then do the following in the root source directory:
>> rm CMakeCache.txt
>> cmake -DBUILTIN_ACE=TRUE . (modify appropriately for out-of-source
>> However, please only do this as a last resort, it isn't a documented
>> method so you're not going to get any support for it.