tf::StampedTransform Throws Segfault

asked 2011-11-11 08:29:25 -0600

Constantin S
296 ●17 ●19 ●31

updated 2014-01-28 17:10:46 -0600

ngrennan
1 ●1 ●1

Hello all, I am attempting the following:

class Durp
{
  tf::TransformListener _tfListener;
  tf::StampedTransform * saveMyTransform;

  Durp() : saveMyTransform(NULL)
  {
    Nodehandle n;
    someSub = n.sub(bla bla bla &callback);
  }

  ~Durp()
  {
    if(saveMyTransform!=NULL) delete saveMyTransform
  }

  void callback(geo_msgs::StampedPoint incPoint)
  {
     tf::StampedTransform tempTransform; //<---- SEGFAULT FOR NO REASON

     try {
       if(saveMyTransform == NULL)
       {
         saveMyTransform = new tf::StampedTransform();
         _tfListener.lookupTransform("bla", "bla2", ros::Time(0), *saveMyTransform);
         // ^^ Segfaults if I comment out tf::StampedTransform tempTransform above
       }

       transform things....
     }
     catch bllaaaa
  }
};

Could someone please shed some light on what I am doing wrong. I would sincerely appreciate, I am ripping my hair out.

Segfault for StampedTransform tempTransform dump:

0x00007fffeba92116 in std::basic_string<char, std::char_traits<char="">, std::allocator<char> >::~basic_string() () from /usr/lib/libstdc++.so.6
(gdb) bt
#0  0x00007fffeba92116 in std::basic_string<char, std::char_traits<char="">, std::allocator<char> >::~basic_string() () from /usr/lib/libstdc++.so.6
#1  0x000000000041d321 in ~StampedTransform (this=0x7fffd4f7b2b0, __in_chrg=<value optimized="" out="">) at /opt/ros/electric/stacks/geometry/tf/include/tf/transform_datatypes.h:89
#2  0x00007fffee75421a in tf::Transformer::setTransform (this=<value optimized="" out="">, transform=<value optimized="" out="">, authority=<value optimized="" out="">)
    at /tmp/buildd/ros-electric-geometry-1.6.1/debian/ros-electric-geometry/opt/ros/electric/stacks/geometry/tf/src/tf.cpp:438
#3  0x00007fffee7670a5 in tf::TransformListener::subscription_callback (this=<value optimized="" out="">, msg=<value optimized="" out="">)
    at /tmp/buildd/ros-electric-geometry-1.6.1/debian/ros-electric-geometry/opt/ros/electric/stacks/geometry/tf/src/transform_listener.cpp:326
#4  0x00007fffee76d1ab in boost::function1<void, boost::shared_ptr<tf::tfmessage_<std::allocator<void=""> > const> const&>::operator() (function_obj_ptr=<value optimized="" out="">, a0=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece.
)
    at /usr/include/boost/function/function_template.hpp:1013
#5  boost::detail::function::void_function_obj_invoker1<boost::function<void ()(boost::shared_ptr<tf::tfmessage_<std::allocator<void=""> > const> const&)>, void, boost::shared_ptr<tf::tfmessage_<std::allocator<void> > const> >::invoke(boost::detail::function::function_buffer&, boost::shared_ptr<tf::tfmessage_<std::allocator<void> > const>) (function_obj_ptr=<value optimized="" out="">, a0=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece.
)
    at /usr/include/boost/function/function_template.hpp:153
#6  0x00007fffee770890 in boost::function1<void, boost::shared_ptr<tf::tfmessage_<std::allocator<void=""> > const> >::operator() (this=0x7fffd0000a70, params=<value optimized="" out="">)
    at /usr/include/boost/function/function_template.hpp:1013
#7  ros::SubscriptionCallbackHelperT<boost::shared_ptr<tf::tfmessage_<std::allocator<void> > const> const&, void>::call (this=0x7fffd0000a70, params=<value optimized="" out="">)
    at /opt/ros/electric/stacks/ros_comm/clients/cpp/roscpp/include/ros/subscription_callback_helper.h:180

Backtrace of when I pass my dynamically allocated Transform in

0  0x00007fffeba921fd in std::string::assign(std::string const&) () from /usr/lib/libstdc++.so.6
#1  0x00007fffee75581e in std::string::operator= (this=<value optimized="" out="">, target_frame=<value optimized="" out="">, source_frame=<value optimized="" out="">, time=..., transform=...)
    at /usr/include/c++/4.4/bits/basic_string.h:506
#2  tf::Transformer::lookupTransform (this=<value optimized="" out="">, target_frame=<value optimized="" out="">, source_frame=<value optimized="" out="">, time=..., transform=...)
    at /tmp/buildd/ros-electric-geometry-1.6.1/debian/ros-electric-geometry/opt/ros/electric/stacks/geometry/tf/src/tf.cpp:483
#3  0x0000000000439494 in RaveServer::displayWaypoint ...

(more)

edit retag flag offensive close merge delete

Comments

Could you post the full code? It might be more helpful.

Ivan Dryanovski ( 2011-11-11 10:56:32 -0600 )edit

Hi Ivan, the code is large and is a module for OpenRAVE. What part of the code would you be interested in? The callback is where the code always segfaults. If I use tempTransform, I segfault in the default constructor. If I comment it out, I segFault in the lookUpTransform. would the code stil

Constantin S ( 2011-11-12 00:52:15 -0600 )edit

be helpful? Thank you Ivan.

Constantin S ( 2011-11-12 00:52:29 -0600 )edit

The best thing to do is make a small test program which reproduces the problem. Often this will help you to find the problem without even needing external help. And it makes it possible to isolate the problem.

tfoote ( 2011-11-14 14:31:20 -0600 )edit

add a comment

3 Answers

Sort by » oldest newest most voted

answered 2011-11-13 20:30:45 -0600

roehling
1951 ●25 ●28 ●43 http://www.fkie.fraunhofer.de/

Your backtrace shows that the segfault occurs in STL code, namely the basic_string allocator. It looks like some other code of yours has corrupted the heap memory management. That's a nasty bug because the corruption might have happened some time before, possibly even in a totally unrelated part of your program. Maybe you have overrun the bounds of an array/vector, or written to an uninitialized pointer that happens to refer to valid (but otherwise used) memory?

I'd try to comment out parts until the segfault disappears, then try to locate the culprit in that code part.

edit flag offensive delete link

Comments

I'd also add that the use of valgrind memtool would likely quickly catch the culprit.

Asomerville ( 2011-11-14 05:27:28 -0600 )edit

...and that using smart pointers (boost:: shared_ptr and auto_ptr) for *all* pointers will avoid a lot of headache.

Asomerville ( 2011-11-14 05:29:14 -0600 )edit

Thanks guys, I will definitely take a look into this, it is a very valid possibility. When you say comment out parts, you mean everything but the StampedTransform? When I comment out the StampedTransform the segfault disappears.

Constantin S ( 2011-11-15 00:54:30 -0600 )edit

I agree with Asomerville: Valgrind can help tremendously. You can install it with `sudo apt-get install valgrind`. The catch is that is slows down your program quite a lot and doubles your memory requirements. However, with a bit of luck Valgrind will tell you exactly where your bug is.

roehling ( 2011-11-15 18:29:36 -0600 )edit

Okay so I ... want to say I fixed it ... but I don't know. This has been a very very weird rabbit hole. I did exactly what you suggested but the opposite way, I started with a base class that worked and slowly started adding everything I needed. Low and behold, I eventually ended up with two

Constantin S ( 2011-11-16 03:45:54 -0600 )edit

identical classes. One worked one segfaulted. So I checked the CMakeLists, the one that worked was a basic CMakeList, the other was a custom I had built in case a person didn't have the openrave ros package. However, now I am thinking the only reason this is working is because it's build with

Constantin S ( 2011-11-16 03:47:06 -0600 )edit

debug flags. I am attaching the differing CMake's below... Could you guys please give me some more intuition on the problem? This is just nuts.

Constantin S ( 2011-11-16 03:47:40 -0600 )edit

add a comment

answered 2011-11-18 00:09:55 -0600

roehling
1951 ●25 ●28 ●43 http://www.fkie.fraunhofer.de/

Your problem could also be related to this question. If different versions of the same library are linked together (possibly because one of them has simply been source-copied into another one), and the linker does not catch this at link-time, runtime errors and segmentation faults can occur.

This is usually a problem with precompiled closed-source libraries. It's worth investigating though.

edit flag offensive delete link

Comments

I'm starting to think this may have been the problem, valgrind did not show any memleaks in my code ... just a whole lot in QT code

Constantin S ( 2011-11-18 01:45:00 -0600 )edit

add a comment

answered 2011-11-16 03:51:35 -0600

Constantin S
296 ●17 ●19 ●31

updated 2011-11-16 03:53:23 -0600

I reduced my problem to differing CMakes. A standard CMakeLists.txt throws no segfault, while the non standard throws a segfault. (The non standard is used when openrave is not part of ros, but installed as a seperate library).

I am assuming that the only reason the standard CMake removes the segfault is because it compiles with debug flags, and I have a hunch the segfault is still there.

Standard CMake

cmake_minimum_required(VERSION 2.4.6)
include($ENV{ROS_ROOT}/core/rosbuild/rosbuild.cmake)

rosbuild_init()

#set the default path for built executables to the "bin" directory
set(EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/bin)
#set the default path for built libraries to the "lib" directory
set(LIBRARY_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/lib)

#uncomment if you have defined messages
rosbuild_genmsg()
#uncomment if you have defined services
#rosbuild_gensrv()

rosbuild_add_executable(RaveServer src/RaveServer.cpp)
rosbuild_add_executable(GenerateGoal src/generate_goal.cpp)
rosbuild_add_library(MoveBase src/moveBase.cpp)
rosbuild_add_library(LiveFeed src/live_feed.cpp)

Non standard CMake

cmake_minimum_required(VERSION 2.4.6)
include($ENV{ROS_ROOT}/core/rosbuild/rosbuild.cmake)

rosbuild_init()

#set the default path for built executables to the "bin" directory
set(EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/bin)
#set the default path for built libraries to the "lib" directory
set(LIBRARY_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/lib)

#uncomment if you have defined messages
rosbuild_genmsg()
#uncomment if you have defined services
#rosbuild_gensrv()

execute_process(COMMAND openrave-config --cflags OUTPUT_VARIABLE OPENRAVE_CXX_FLAGS)
execute_process(COMMAND openrave-config --libs-core OUTPUT_VARIABLE OPENRAVE_LINK_FLAGS)
execute_process(COMMAND openrave-config --libs OUTPUT_VARIABLE OPENRAVE_LIB_FLAGS)
execute_process(COMMAND openrave-config --prefix OUTPUT_VARIABLE OPENRAVE_PREFIX)

#Set up - replace newlines ... faiiil!!!
string(REGEX REPLACE "[\r\n]" "" OPENRAVE_CXX_FLAGS ${OPENRAVE_CXX_FLAGS})
string(REGEX REPLACE "[\r\n]" "" OPENRAVE_LINK_FLAGS ${OPENRAVE_LINK_FLAGS})
string(REGEX REPLACE "[\r\n]" "" OPENRAVE_LIB_FLAGS ${OPENRAVE_LIB_FLAGS})
string(REGEX REPLACE "[\r\n]" "" OPENRAVE_LIB_DIR "${OPENRAVE_PREFIX}/lib")

rosbuild_add_executable(RaveServer src/RaveServer.cpp)
rosbuild_add_executable(GenerateGoal src/generate_goal.cpp)
rosbuild_add_library(MoveBase src/moveBase.cpp)
rosbuild_add_library(LiveFeed src/live_feed.cpp)

set_target_properties(RaveServer PROPERTIES COMPILE_FLAGS "${OPENRAVE_CXX_FLAGS}" LINK_FLAGS "${OPENRAVE_LINK_FLAGS}" INSTALL_RPATH "${OPENRAVE_LIB_DIR}")
set_target_properties(MoveBase PROPERTIES COMPILE_FLAGS "${OPENRAVE_CXX_FLAGS}" LINK_FLAGS "${OPENRAVE_LIB_FLAGS}")

edit flag offensive delete link

Comments

Adjusting the compile may provide an illusory solution. It may just juggle the memory around enough to avoid trampling on something temporarily, but it won't really fix your problem. You have a memory corruption somewhere. The problem won't be solve until you find out why/where.

Asomerville ( 2011-11-16 08:16:03 -0600 )edit

I completely agree, and I am worried it's going to come out at any time. I'll use the tool suggested to me above.

Constantin S ( 2011-11-16 09:14:18 -0600 )edit

add a comment

tf::StampedTransform Throws Segfault

Comments

3 Answers

Comments

Comments

Comments

Question Tools

Stats

Related questions

tf::StampedTransform Throws Segfault edit

Comments

3 Answers

Comments

Comments

Comments

Question Tools

Stats

Related questions

tf::StampedTransform Throws Segfault