Ask Your Question

Triclops SDK Function Breaks ros::NodeHandle

asked 2014-01-30 06:03:12 -0600

Andrew Capodieci gravatar image

updated 2014-01-30 06:09:04 -0600

Hello everyone,

I have a problem incorporating Point Grey Research's Triclops SDK into ROS. I've created a simple test ROS package that illustrates this problem based on the simple C++ publisher shown in the following tutorial: . Here is the code:

#include "ros/ros.h"
#include "std_msgs/String.h"
#include "triclops.h"

#include  <sstream>

 * Function to handle error checking for the Triclops SDK
void triclopsErrorHandler(const char* function_name, TriclopsError te) {
    if(te != TriclopsErrorOk) {
            std::cout &lt;&lt; "TRICLOPS_ERROR: " &lt;&lt; function_name &lt;&lt; " reported " &lt;&lt; triclopsErrorToString(te) &lt;&lt; "." &lt;&lt; std::endl;

 * This tutorial demonstrates simple sending of messages over the ROS system.
int main(int argc, char **argv)
  ros::init(argc, argv, "talker");

  ros::NodeHandle n;

  ros::Publisher chatter_pub = n.advertise<std_msgs::string>("chatter", 1000);

  ros::Rate loop_rate(10);

  int count = 0;
  TriclopsContext shortContext;
  TriclopsError te;
  te = triclopsGetDefaultContextFromFile(&amp;shortContext, "../");
  triclopsErrorHandler("triclopsGetDefaultContextFromFile", te);
  while (ros::ok())
    std_msgs::String msg;

    std::stringstream ss;
    ss &lt;&lt; "hello world " &lt;&lt; count; = ss.str();




  return 0;

Whenever the following line:

> te = triclopsGetDefaultContextFromFile(&shortContext, "../");

is NOT commented, I get the following segfault in gdb:

$ gdb ./bin/testTriclops 
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http:"" gpl.html="" licenses="">
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http:"" gdb-linaro="">...
Reading symbols from /home/andrew-am3p/fuerte_workspace/sandbox/testTriclops/bin/testTriclops...done.
(gdb) run
Starting program: /home/andrew-am3p/fuerte_workspace/sandbox/testTriclops/bin/testTriclops 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/".
testTriclops: malloc.c:2451: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char *) &amp;((av)-&gt;bins[((1) - 1) * 2])) -         __builtin_offsetof (struct malloc_chunk, fd)))) &amp;&amp; old_size == 0) || ((unsigned long) (old_size) &gt;= (unsigned long)    ((((__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * (sizeof(size_t))) - 1)) &amp; ~((2 * (sizeof(size_t))) - 1))) &amp;&amp;     ((old_top)-&gt;size &amp; 0x1) &amp;&amp; ((unsigned long)old_end &amp; pagemask) == 0)' failed.

Program received signal SIGABRT, Aborted.
0xb7fdd424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fdd424 in __kernel_vsyscall ()
#1  0xb7b5f1df in raise () from /lib/i386-linux-gnu/
#2  0xb7b62825 in abort () from /lib/i386-linux-gnu/
#3  0xb7ba6469 in ?? () from /lib/i386-linux-gnu/
#4  0xb7ba9293 in ?? () from /lib/i386-linux-gnu/
#5  0xb7baadec in malloc () from /lib/i386-linux-gnu/
#6  0xb7deb627 in operator new(unsigned int) () from /usr/lib/i386-linux-gnu/
#7  0xb7f92124 in ros::initInternalTimerManager() () from /opt/ros/fuerte/lib/
#8  0xb7f74e65 in ros::start() () from /opt/ros/fuerte/lib/ ...
edit retag flag offensive close merge delete


I seem to recall this is because PointGrey statically links in some libraries that ROS also uses, and you get all sorts of bizarre symbol conflicts. It's been a while since I have looked at this, though.

mjcarroll gravatar image mjcarroll  ( 2014-01-30 08:55:42 -0600 )edit

the point grey triclops library is a static library (triclops.a) so this makes the cmake I had to put link_libraries(triclops) so that the triclops libraries were linked first and so ROS didn't depend on it. Would this have prevented the issue you're talking about?

Andrew Capodieci gravatar image Andrew Capodieci  ( 2014-01-30 09:22:31 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2014-01-30 07:29:30 -0600

ahendrix gravatar image

This looks more like a memory corruption bug than anything specifically related to ROS. Note that the stacktrace shows that it's failing somewhere inside of malloc().

My best guess is that the call to triclopsGetDefaultContextFromFile is corrupting memory or the memory allocator in some way; either the call itself or the arguments that you're passing to it.

A tool like valgrind may be able to help spot memory corruption issues earlier.

edit flag offensive delete link more


I don't believe this is the problem because I have a standalone C++ library that uses the same function without ROS and it works. The problem only arises when I try to port my standalone C++ library into a ros package.

Andrew Capodieci gravatar image Andrew Capodieci  ( 2014-01-30 08:05:12 -0600 )edit

Also isn't the code never getting to call triclopsGetDefaultContextFromFile because the segfault occurs in the construction of the NodeHandle, which is the 2nd line of code?

Andrew Capodieci gravatar image Andrew Capodieci  ( 2014-01-30 08:06:57 -0600 )edit

It's hard to tell where the NodeHandle creation that's triggering the error is happening, because the line numbers reported by GDB don't match up with the code sample that you've posted.

ahendrix gravatar image ahendrix  ( 2014-01-30 10:03:18 -0600 )edit

I'm still going to recommend running your node in valgrind to see if it can find any bad memory accesses.

ahendrix gravatar image ahendrix  ( 2014-01-30 10:05:24 -0600 )edit

I think I copy and pasted the gdb run from when I had comments in the code. I ran it again and it occurs on line 24, which corresponds to the ros::NodeHandle n; line in the sample code. I'll try valgrind just in case and let you know tomorrow what I get for an output.

Andrew Capodieci gravatar image Andrew Capodieci  ( 2014-01-30 11:02:22 -0600 )edit

I can confirm the bug that is very alike. I do not even call any function from the point grey code. Moreover, I don't even include their stuff. The memory corruption occurs right after linking. So a single change in CMake causes the bug. If I do not link against it - I run everything ok

nios gravatar image nios  ( 2015-06-25 11:43:07 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


Asked: 2014-01-30 06:03:12 -0600

Seen: 476 times

Last updated: Jan 30 '14