rttlua crash under xenomai.

Hello,
I recently started converting our xml deployments into lua and at some
point i runned into issue of crashing rttlua deployer. When rttlua-xenomai
is used with ros it receive SIGSEGV after some time of running (not very
deterministic).

Here is backtrace from gdb :
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff7ea0b00 (LWP 7281)]
0x00007ffff5681067 in xeno_sigwinch_handler () from
/opt/xenomai/lib/libxenomai.so.0
(gdb) bt
#0 0x00007ffff5681067 in xeno_sigwinch_handler () from
/opt/xenomai/lib/libxenomai.so.0
#1 0x00007ffff56810f3 in xeno_sigshadow_handler () from
/opt/xenomai/lib/libxenomai.so.0
#2 0x00007ffff6cc13d5 in ?? () from /lib/x86_64-linux-gnu/libreadline.so.6
#3 <signal handler called>
#4 0x00007ffff6885ccd in write () from
/lib/x86_64-linux-gnu/libpthread.so.0
#5 0x00007fffe1151fd9 in ros::PollSet::signal() () from
/opt/ros/fuerte/lib/libroscpp.so
#6 0x00007fffe10e93cf in ros::TopicManager::publish(std::string const&,
boost::function<ros::SerializedMessage ()> const&, ros::SerializedMessage&)
() from /opt/ros/fuerte/lib/libroscpp.so
#7 0x00007fffe10dc11c in
ros::Publisher::publish(boost::function<ros::SerializedMessage ()> const&,
ros::SerializedMessage&) const () from /opt/ros/fuerte/lib/libroscpp.so
#8 0x00007fffcf54bf95 in void
ros::Publisher::publish<std_msgs::Float32_<std::allocator<void> >
>(std_msgs::Float32_<std::allocator<void> > const&) const ()
from
/opt/ros-local/fuerte/stacks/rtt_ros_comm/rtt_std_msgs/lib/orocos/xenomai/types/librtt-std_msgs-ros-transport-xenomai.so
#9 0x00007fffcf54c038 in
ros_integration::RosPubChannelElement<std_msgs::Float32_<std::allocator<void>
> >::publish() ()
from
/opt/ros-local/fuerte/stacks/rtt_ros_comm/rtt_std_msgs/lib/orocos/xenomai/types/librtt-std_msgs-ros-transport-xenomai.so
#10 0x00007fffcf4cab93 in ros_integration::RosPublishActivity::loop() ()
from
/opt/ros-local/fuerte/stacks/rtt_ros_comm/rtt_std_msgs/lib/orocos/xenomai/types/librtt-std_msgs-ros-transport-xenomai.so
#11 0x00007ffff7b261e6 in RTT::os::thread_function (t=0x7db2a0) at
/opt/ros-local/fuerte/stacks/orocos_toolchain/rtt/rtt/os/Thread.cpp:182
#12 0x00007ffff7b29e81 in RTT::os::rtos_xeno_thread_wrapper
(cookie=0x7dad30) at
/opt/ros-local/fuerte/stacks/orocos_toolchain/rtt/rtt/os/xenomai/fosi_internal.cpp:193
#13 0x00007ffff6a98829 in rt_task_trampoline () from
/opt/xenomai/lib/libnative.so.3
#14 0x00007ffff687ee9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#15 0x00007ffff5d99cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#16 0x0000000000000000 in ?? ()

It looks like the problem is cased by libreadline but i am not able to
build rttlua deployer without libreadline even with NO_GPL set to ON.

Pozdrawiam
Konrad Banachowicz

rttlua crash under xenomai.

Hi Konrad,

On Tue, Nov 20, 2012 at 05:24:31PM +0100, Konrad Banachowicz wrote:
> Hello,
> I recently started converting our xml deployments into lua and at some point i
> runned into issue of crashing rttlua deployer. When rttlua-xenomai is used with
> ros it receive SIGSEGV after some time of running (not very deterministic).
>
> Here is backtrace from gdb :
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7ffff7ea0b00 (LWP 7281)]
> 0x00007ffff5681067 in xeno_sigwinch_handler () from /opt/xenomai/lib/
> libxenomai.so.0
> (gdb) bt
> #0 0x00007ffff5681067 in xeno_sigwinch_handler () from /opt/xenomai/lib/
> libxenomai.so.0
> #1 0x00007ffff56810f3 in xeno_sigshadow_handler () from /opt/xenomai/lib/
> libxenomai.so.0
> #2 0x00007ffff6cc13d5 in ?? () from /lib/x86_64-linux-gnu/libreadline.so.6
> #3 <signal handler called>
> #4 0x00007ffff6885ccd in write () from /lib/x86_64-linux-gnu/libpthread.so.0
> #5 0x00007fffe1151fd9 in ros::PollSet::signal() () from /opt/ros/fuerte/lib/
> libroscpp.so
> #6 0x00007fffe10e93cf in ros::TopicManager::publish(std::string const&,
> boost::function<ros::SerializedMessage ()> const&, ros::SerializedMessage&) ()
> from /opt/ros/fuerte/lib/libroscpp.so
> #7 0x00007fffe10dc11c in ros::Publisher::publish(boost::function
> <ros::SerializedMessage ()> const&, ros::SerializedMessage&) const () from /opt
> /ros/fuerte/lib/libroscpp.so
> #8 0x00007fffcf54bf95 in void ros::Publisher::publish<std_msgs::Float32_
> <std::allocator<void> > >(std_msgs::Float32_<std::allocator<void> > const&)
> const ()
> from /opt/ros-local/fuerte/stacks/rtt_ros_comm/rtt_std_msgs/lib/orocos/
> xenomai/types/librtt-std_msgs-ros-transport-xenomai.so
> #9 0x00007fffcf54c038 in ros_integration::RosPubChannelElement
> <std_msgs::Float32_<std::allocator<void> > >::publish() ()
> from /opt/ros-local/fuerte/stacks/rtt_ros_comm/rtt_std_msgs/lib/orocos/
> xenomai/types/librtt-std_msgs-ros-transport-xenomai.so
> #10 0x00007fffcf4cab93 in ros_integration::RosPublishActivity::loop() () from /
> opt/ros-local/fuerte/stacks/rtt_ros_comm/rtt_std_msgs/lib/orocos/xenomai/types/
> librtt-std_msgs-ros-transport-xenomai.so
> #11 0x00007ffff7b261e6 in RTT::os::thread_function (t=0x7db2a0) at /opt/
> ros-local/fuerte/stacks/orocos_toolchain/rtt/rtt/os/Thread.cpp:182
> #12 0x00007ffff7b29e81 in RTT::os::rtos_xeno_thread_wrapper (cookie=0x7dad30)
> at /opt/ros-local/fuerte/stacks/orocos_toolchain/rtt/rtt/os/xenomai/
> fosi_internal.cpp:193
> #13 0x00007ffff6a98829 in rt_task_trampoline () from /opt/xenomai/lib/
> libnative.so.3
> #14 0x00007ffff687ee9a in start_thread () from /lib/x86_64-linux-gnu/
> libpthread.so.0
> #15 0x00007ffff5d99cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6
> #16 0x0000000000000000 in ?? ()
>
> It looks like the problem is cased by libreadline but i am not able to build

Yes, it has do do with the window resize signal being sent. Peter
started a thread on the xenomai ML some time ago:

http://thread.gmane.org/gmane.linux.real-time.xenomai.users/11802/focus=...

AFAIK it was fixed in these two commits:

89586b71126a06e91a5bbe0ffb510bdaeccd5cf9
b73b71edc5e7094ba1e42cb209611105c18ad2a7

I suppose we have to port this fix to rttlua.

> rttlua deployer without libreadline even with NO_GPL set to ON.

Why not?

Markus

rttlua crash under xenomai.

2012/11/21 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
>
> Hi Konrad,
>
> On Tue, Nov 20, 2012 at 05:24:31PM +0100, Konrad Banachowicz wrote:
> > Hello,
> > I recently started converting our xml deployments into lua and at some point i
> > runned into issue of crashing rttlua deployer. When rttlua-xenomai is used with
> > ros it receive SIGSEGV after some time of running (not very deterministic).
> >
> > Here is backtrace from gdb :
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x7ffff7ea0b00 (LWP 7281)]
> > 0x00007ffff5681067 in xeno_sigwinch_handler () from /opt/xenomai/lib/
> > libxenomai.so.0
> > (gdb) bt
> > #0 0x00007ffff5681067 in xeno_sigwinch_handler () from /opt/xenomai/lib/
> > libxenomai.so.0
> > #1 0x00007ffff56810f3 in xeno_sigshadow_handler () from /opt/xenomai/lib/
> > libxenomai.so.0
> > #2 0x00007ffff6cc13d5 in ?? () from /lib/x86_64-linux-gnu/libreadline.so.6
> > #3 <signal handler called>
> > #4 0x00007ffff6885ccd in write () from /lib/x86_64-linux-gnu/libpthread.so.0
> > #5 0x00007fffe1151fd9 in ros::PollSet::signal() () from /opt/ros/fuerte/lib/
> > libroscpp.so
> > #6 0x00007fffe10e93cf in ros::TopicManager::publish(std::string const&,
> > boost::function<ros::SerializedMessage ()> const&, ros::SerializedMessage&) ()
> > from /opt/ros/fuerte/lib/libroscpp.so
> > #7 0x00007fffe10dc11c in ros::Publisher::publish(boost::function
> > <ros::SerializedMessage ()> const&, ros::SerializedMessage&) const () from /opt
> > /ros/fuerte/lib/libroscpp.so
> > #8 0x00007fffcf54bf95 in void ros::Publisher::publish<std_msgs::Float32_
> > <std::allocator<void> > >(std_msgs::Float32_<std::allocator<void> > const&)
> > const ()
> > from /opt/ros-local/fuerte/stacks/rtt_ros_comm/rtt_std_msgs/lib/orocos/
> > xenomai/types/librtt-std_msgs-ros-transport-xenomai.so
> > #9 0x00007fffcf54c038 in ros_integration::RosPubChannelElement
> > <std_msgs::Float32_<std::allocator<void> > >::publish() ()
> > from /opt/ros-local/fuerte/stacks/rtt_ros_comm/rtt_std_msgs/lib/orocos/
> > xenomai/types/librtt-std_msgs-ros-transport-xenomai.so
> > #10 0x00007fffcf4cab93 in ros_integration::RosPublishActivity::loop() () from /
> > opt/ros-local/fuerte/stacks/rtt_ros_comm/rtt_std_msgs/lib/orocos/xenomai/types/
> > librtt-std_msgs-ros-transport-xenomai.so
> > #11 0x00007ffff7b261e6 in RTT::os::thread_function (t=0x7db2a0) at /opt/
> > ros-local/fuerte/stacks/orocos_toolchain/rtt/rtt/os/Thread.cpp:182
> > #12 0x00007ffff7b29e81 in RTT::os::rtos_xeno_thread_wrapper (cookie=0x7dad30)
> > at /opt/ros-local/fuerte/stacks/orocos_toolchain/rtt/rtt/os/xenomai/
> > fosi_internal.cpp:193
> > #13 0x00007ffff6a98829 in rt_task_trampoline () from /opt/xenomai/lib/
> > libnative.so.3
> > #14 0x00007ffff687ee9a in start_thread () from /lib/x86_64-linux-gnu/
> > libpthread.so.0
> > #15 0x00007ffff5d99cbd in clone () from /lib/x86_64-linux-gnu/libc.so.6
> > #16 0x0000000000000000 in ?? ()
> >
> > It looks like the problem is cased by libreadline but i am not able to build
>
> Yes, it has do do with the window resize signal being sent. Peter
> started a thread on the xenomai ML some time ago:
>
> http://thread.gmane.org/gmane.linux.real-time.xenomai.users/11802/focus=...
>
> AFAIK it was fixed in these two commits:
>
> 89586b71126a06e91a5bbe0ffb510bdaeccd5cf9
> b73b71edc5e7094ba1e42cb209611105c18ad2a7
>
> I suppose we have to port this fix to rttlua.
>
> > rttlua deployer without libreadline even with NO_GPL set to ON.
>
> Why not?
Because liblua internally use libreadline.
> Markus

rttlua crash under xenomai.

Hi Konrad,

On Wed, Nov 21, 2012 at 10:21:59AM +0100, Konrad Banachowicz wrote:
> 2012/11/21 Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
...

> > > It looks like the problem is cased by libreadline but i am not able to build
> >
> > Yes, it has do do with the window resize signal being sent. Peter
> > started a thread on the xenomai ML some time ago:
> >
> > http://thread.gmane.org/gmane.linux.real-time.xenomai.users/11802/focus=...
> >
> > AFAIK it was fixed in these two commits:
> >
> > 89586b71126a06e91a5bbe0ffb510bdaeccd5cf9
> > b73b71edc5e7094ba1e42cb209611105c18ad2a7
> >
> > I suppose we have to port this fix to rttlua.
> >
> > > rttlua deployer without libreadline even with NO_GPL set to ON.
> >
> > Why not?
> Because liblua internally use libreadline.

No, it doesn't, only the REPLs rttlua (ocl/lua/lua-repl.[ch]) or
lua(5.1) do. But you are right, NO_GPL is not honoured by Lua, could
you try the attached patch?

Markus

>From ddd9728092a4d2691267e41589468c7213f51794 Mon Sep 17 00:00:00 2001
From: Markus Klotzbuecher <markus [dot] klotzbuecher [..] ...>
Date: Wed, 21 Nov 2012 11:24:46 +0100
Subject: [PATCH] rttlua: honour NO_GPL

---
lua/CMakeLists.txt | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/lua/CMakeLists.txt b/lua/CMakeLists.txt
index 56496d1..b8fd7e7 100644