crazyorc's profile - activity

@bit-pirate Consider yourself lucky! A lot has changed in the past year for both ROS and Ubuntu but I don't see any changes to fix this. I would expect my example to still fail since I don't see any changes (rushed glance), but if it works now that's awesome.

Excellent point. My experience bias blinded me a little. Playback of rosbags has been the source of many of these exceptions for me.

The exception is because Internally ros::Time objects use int64_t variables and cast to uint32_t when returning the result. When a time value is negative, the value exceeds what an uint32_t variable can represent. The result is the exception you are seeing is thrown.

This sample code that generates the exception you are seeing.

try {
  ros::Time test = ros::Time::now() - ros::Duration(0.01);
}
catch(std::runtime_error& ex) {
  ROS_ERROR("Exception: [%s]", ex.what());
}

Possible solutions:

1. Wrap your code in try-catch blocks and deal with the resulting issues
2. Call toSec() on time/duration objects and do the math manually

TL;DR

Here's where the exception is thrown (source here)

void normalizeSecNSecUnsigned(int64_t& sec, int64_t& nsec)
{
  int64_t nsec_part = nsec % 1000000000L;
  int64_t sec_part = sec + nsec / 1000000000L;
  if (nsec_part < 0)
  {
      nsec_part += 1000000000L;
      --sec_part;
  }

  if (sec_part < 0 || sec_part > UINT_MAX)
    throw std::runtime_error("Time is out of dual 32-bit range");

  sec = sec_part;
  nsec = nsec_part;
}

This code is one of several places where the exception might be generated. Subtraction is implemented as "negative addition". (source here)

template<class T, class D>
T TimeBase<T, D>::operator-(const D &rhs) const
{
  return *static_cast<const T*>(this) + ( -rhs);
}

template<class T, class D>
T TimeBase<T, D>::operator+(const D &rhs) const
{
  int64_t sec_sum  = (int64_t)sec  + (int64_t)rhs.sec;
  int64_t nsec_sum = (int64_t)nsec + (int64_t)rhs.nsec;

  // Throws an exception if we go out of 32-bit range
  normalizeSecNSecUnsigned(sec_sum, nsec_sum);

  // now, it's safe to downcast back to uint32 bits
  return T((uint32_t)sec_sum, (uint32_t)nsec_sum);
}

The problem appears to be that roscpp and rosbag_storage include message_forward.h but haven't included any C++ stdlib include files which would cause __GLIBCXX__ or _LIBCPP_VERSION to be defined. Edited solution patch to include a better fix.

The following patch fixes the issue (edit: use this patch instead to fix both roscpp and rosbag_storage).

--- src/roscpp_core/roscpp_traits/include/ros/message_forward.h.orig    2015-04-22 15:04:29.000000000 -0700
+++ src/roscpp_core/roscpp_traits/include/ros/message_forward.h 2015-04-22 15:46:31.000000000 -0700
@@ -28,6 +28,11 @@
 #ifndef ROSLIB_MESSAGE_FORWARD_H
 #define ROSLIB_MESSAGE_FORWARD_H

+// Make sure that either __GLIBCXX__ or _LIBCPP_VERSION is defined.
+#include <cstddef>
+
 // C++ standard section 17.4.3.1/1 states that forward declarations of STL types
 // that aren't specializations involving user defined types results in undefined
 // behavior. Apparently only libc++ has a problem with this and won't compile it.

I've been following the instructions on the ROS wiki for building on Mac OS X. I'm running 10.10.3 with Xcode 6.3 (with CLI tools 6.3 installed). Everything works until it tries to build rosbag_storage.

Building uncompressed_stream.cpp the following errors occur:

/usr/local/include/boost/format/format_fwd.hpp:24:69: error: no type named 'allocator' in namespace 'std'
        class Tr = BOOST_IO_STD char_traits<Ch>, class Alloc = std::allocator<Ch> >
                                                               ~~~~~^
/usr/local/include/boost/format/format_fwd.hpp:24:78: error: expected ',' or '>' in template-parameter-list
        class Tr = BOOST_IO_STD char_traits<Ch>, class Alloc = std::allocator<Ch> >
                                                                             ^
/usr/local/include/boost/format/format_fwd.hpp:24:83: error: expected unqualified-id
        class Tr = BOOST_IO_STD char_traits<Ch>, class Alloc = std::allocator<Ch> >
                                                                                  ^
/usr/local/include/boost/format/format_fwd.hpp:27:13: error: unknown type name 'basic_format'
    typedef basic_format<char >     format;
            ^
/usr/local/include/boost/format/format_fwd.hpp:27:25: error: expected unqualified-id
    typedef basic_format<char >     format;
                        ^
/usr/local/include/boost/format/format_fwd.hpp:30:13: error: unknown type name 'basic_format'
    typedef basic_format<wchar_t >  wformat;
            ^
/usr/local/include/boost/format/format_fwd.hpp:30:25: error: expected unqualified-id
    typedef basic_format<wchar_t >  wformat;

Apparently my Google foo is not up to snuff as the only thing related to this has to do with a missing C++ std library file that is missing (<__debug>). Copying that file from Xcode into CLI tools doesn't fix the issue.

Any ideas how to get past this error?

EDIT: Same error with Xcode 6.3.1 (and matching CLI tools) installed

After some deeper code inspection, the crash occurred in an instance of a class that was being accessed via an interface pointer which the class didn't inherit from. All the required methods were implemented but none of them were declared virtual.

Modifying the class to inherit from the expected interface definition got rid of the crash.

In GDB, I see "SIGSEGV" signal received and then the following output

0x00000000004603e0 in typeinfo for boost::io::basic_altstringbuf<char, std::char_traits<char>, std::allocator<char> > ()

A node handle is declared elsewhere and set via an accessor in the class where this crash is occuring. The code leading up to the line where crash occurs is creating a publisher object using that node handle. Once the publisher is created, a function is called and passed that publisher object by reference

Logging statements before the function call that is crashing show that the all the objects involved appear to be valid.

Any hints/ideas what this error means or how to debug this?