We’ve amassed quite a codebase for R2 (still running 12.04 and ROS Hydro debian packages). We’ve found something that I find is concerning, and may point to some critical, underlying problems.
If we run our on-board control system (rttlua with a couple dozen components and ROS topics/services) after building our code with `catkin_make` it has a tendency to coredump without warning. We’ve been unable to identify any single action or event that causes it. The backtrace generally starts with some operation call (that we didn’t knowingly do) and ends with some std::vector<char> (which we use on occasion).
However, when we build our code with `catkin_make -DCMAKE_BUILD_TYPE=Release`, the mystery coredump doesn’t happen.
Has anyone else found a need to use the optimizations in Release builds to have safe execution of their Orocos components? Likewise, can anyone guess at what would cause operation calls to happen without cause, but only when not using Release?
--
Dustin Gooding
NASA/JSC Robotics
sensitivity to compiler optimizations
Do you have the same issues if you build all of RTT / rtt_ros_integration
from the hydro-devel source, instead of using the debs?
-j
On Fri, Feb 12, 2016 at 11:44 AM Gooding, Dustin R. (JSC-ER411) <
dustin [dot] r [dot] gooding [..] ...> wrote:
> We’ve amassed quite a codebase for R2 (still running 12.04 and ROS Hydro
> debian packages). We’ve found something that I find is concerning, and may
> point to some critical, underlying problems.
>
> If we run our on-board control system (rttlua with a couple dozen
> components and ROS topics/services) after building our code with
> `catkin_make` it has a tendency to coredump without warning. We’ve been
> unable to identify any single action or event that causes it. The
> backtrace generally starts with some operation call (that we didn’t
> knowingly do) and ends with some std::vector<char> (which we use on
> occasion).
>
> However, when we build our code with `catkin_make
> -DCMAKE_BUILD_TYPE=Release`, the mystery coredump doesn’t happen.
>
> Has anyone else found a need to use the optimizations in Release builds to
> have safe execution of their Orocos components? Likewise, can anyone guess
> at what would cause operation calls to happen without cause, but only when
> not using Release?
>
> --
> *Dustin Gooding*
> NASA/JSC Robotics
>
>
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
sensitivity to compiler optimizations
On Feb 12, 2016, at 10:53 AM, Jonathan Bohren <jonathan [dot] bohren [..] ...jonathan [dot] bohren [..] ...>> wrote:
Do you have the same issues if you build all of RTT / rtt_ros_integration from the hydro-devel source, instead of using the debs?
-j
On Fri, Feb 12, 2016 at 11:44 AM Gooding, Dustin R. (JSC-ER411) <dustin [dot] r [dot] gooding [..] ...dustin [dot] r [dot] gooding [..] ...>> wrote:
We’ve amassed quite a codebase for R2 (still running 12.04 and ROS Hydro debian packages). We’ve found something that I find is concerning, and may point to some critical, underlying problems.
We generally avoid compiling third-party code if debs are provided. So no, I haven’t, sorry. Do you expect the issue is with mismatched compiler optimizations between the rtt debs (which are likely Release) and our non-Release code that links against it?
--
dustin
sensitivity to compiler optimizations
On Fri, Feb 12, 2016 at 12:05 PM Gooding, Dustin R. (JSC-ER411) <
dustin [dot] r [dot] gooding [..] ...> wrote:
> We generally avoid compiling third-party code if debs are provided. So
no, I haven’t, sorry. Do you expect the issue is with mismatched compiler
optimizations between the rtt debs (which are likely Release) and our
non-Release code that links against it?
It will definitely let you rule out some sort of rare binary mismatch like
you're talking about, but it's more likely due to something that's
misbehaving in Release mode and is only getting caught by some of the
additional oversight in Debug mode. It's also easier to debug if the
problem still occurs when you build the whole stack from source in Debug
mode.
-j