Added the possibility to check the used middleware for memory operations. #2

deeplearningrobotics · 2018-06-27T21:59:56Z

This change is

dejanpan · 2018-06-27T23:34:37Z

@wjwwood fyi, performance_test tool now includes memory_tools too

wjwwood · 2018-06-27T23:37:39Z

🆒

serge-nikulin

A design problem:

If a user fails to properly initialize the memory checker, it will fail silently giving the user a false assurance that there are no unwanted calls.

We have seen it today on your system.

Please introduce a check before the steady time that all possible calls (malloc, realloc, calloc, and free) are captured indeed.

@wjwwood, can this falsifiability be somehow automated and be done inside of the tool itself?

serge-nikulin · 2018-06-27T23:14:09Z

performance_test/src/data_running/data_runner_base.hpp

+#ifdef MEMORY_TOOLS_ENABLED
+      osrf_testing_tools_cpp::memory_tools::initialize();
+
+      auto on_unexpected_memory =


auto const on_unexpected_memory

For my own education:

What happens with this lambda when you get out of scope?

Should not you use a plain function callback in such a case?

The lambda is wrapped in a https://en.cppreference.com/w/cpp/utility/functional/function. So this should fine.

The function is now also const, as requested and correct.

serge-nikulin · 2018-06-27T23:25:31Z

performance_test/src/data_running/data_runner_base.hpp

+
+      auto on_unexpected_memory =
+              [](osrf_testing_tools_cpp::memory_tools::MemoryToolsService &service) {
+                std::cerr << "unexpected malloc";


This is a misleading statement. It might be malloc, free, calloc, or realloc.

I would create separate callbacks for each call with the corresponding messages.

This std::cerr should not be there. The next line already prints which type of allocation happened:

malloc (not expected) 104 -> 0x2db7440 Stack trace (most recent call last): #33 Object "[0xffffffffffffffff]", at 0xffffffffffffffff, in #32 Object "/home/andreas.pasternak/1429/apex_ws/src/performance_test/performance_test/cmake-build-debug/perf_test", at 0x40a168, in #31 Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7f70b6cd282f, in __libc_start_main #30 Object "/home/andreas.pasternak/1429/apex_ws/src/p

I removed this line. Then multiple callbacks are not required at the moment.

serge-nikulin · 2018-06-27T23:29:12Z

performance_test/src/data_running/data_runner_base.hpp

+                service.print_backtrace();
+              };
+      osrf_testing_tools_cpp::memory_tools::on_unexpected_calloc(on_unexpected_memory);
+      osrf_testing_tools_cpp::memory_tools::on_unexpected_free(on_unexpected_memory);


on_unexpected_free

serge-nikulin · 2018-06-27T23:29:27Z

performance_test/src/data_running/data_runner_base.hpp

+                service.print_backtrace();
+              };
+      osrf_testing_tools_cpp::memory_tools::on_unexpected_calloc(on_unexpected_memory);
+      osrf_testing_tools_cpp::memory_tools::on_unexpected_free(on_unexpected_memory);


on_unexpected_calloc

serge-nikulin · 2018-06-27T23:29:48Z

performance_test/src/data_running/data_runner_base.hpp

+      osrf_testing_tools_cpp::memory_tools::on_unexpected_calloc(on_unexpected_memory);
+      osrf_testing_tools_cpp::memory_tools::on_unexpected_free(on_unexpected_memory);
+      osrf_testing_tools_cpp::memory_tools::on_unexpected_malloc(on_unexpected_memory);
+      osrf_testing_tools_cpp::memory_tools::on_unexpected_realloc(on_unexpected_memory);


on_unexpected_malloc

serge-nikulin · 2018-06-27T23:31:28Z

performance_test/src/data_running/data_runner_base.hpp

+      osrf_testing_tools_cpp::memory_tools::on_unexpected_free(on_unexpected_memory);
+      osrf_testing_tools_cpp::memory_tools::on_unexpected_malloc(on_unexpected_memory);
+      osrf_testing_tools_cpp::memory_tools::on_unexpected_realloc(on_unexpected_memory);
+


on_unexpected_realloc

Sorry for the comments' placements, it's probably my Chrome.

serge-nikulin · 2018-06-27T23:37:07Z

README.md

@@ -29,7 +29,7 @@ mkdir -p perf_test_ws/src
 cd perf_test_ws/src
 git clone git@github.com:ApexAI/performance_test
 cd ..
-ament build --parallel --build-tests --cmake-args -DCMAKE_BUILD_TYPE=Debug --
+ament build --parallel --build-tests --cmake-args -DCMAKE_BUILD_TYPE=Release


--parallel is known to be problematic under certain conditions.

If a user wants to build fast, this user will use this option. Otherwise, it's a premature optimization.

I am not a patient person. ;)

wjwwood · 2018-06-28T00:18:46Z

Please introduce a check before the steady time that all possible calls (malloc, realloc, calloc, and free) are captured indeed.

Until I can make function like this in osrf_testing_tools_cpp, you can use something like this:

void
malloc_test_function(const std::string & str)
{
  void * some_memory = std::malloc(1024);
  // We need to do something with the malloc'ed memory to make sure this
  // function doesn't get optimized away.  memset isn't enough, so we do a
  // memcpy from a passed in string, which is enough to keep the optimizer away.
  // see: https://github.com/osrf/osrf_testing_tools_cpp/pull/8
  memcpy(some_memory, str.c_str(), str.length());
  std::free(some_memory);
}

void
assert_memory_tools_is_working()
{
  bool saw_malloc = false;
  on_malloc([&]() {
    saw_malloc = true;
  });
  OSRF_TESTING_TOOLS_CPP__SCOPE_EXIT({on_malloc(nullptr);});
  {
    const std::string test_str = "test message";
    malloc_test_function(test_str);
  }
  ASSERT_TRUE(saw_malloc);
}

@wjwwood, can this falsifiability be somehow automated and be done inside of the tool itself?

I don't think it makes sense to do it implicitly, though having a function to test for it is certainly useful enough to have it in osrf_testing_tools_cpp directly. The reason I would not do it implicitly is that if the test does something other than test for memory allocations, then you'd like the rest of the test to happen even if the system you're on does not support memory tools.

If I had an implicit check I'd want to make a distinction between "memory tools is supported on this platform and expected, but not catching things" and "memory tools may or may not be expected to work on this platform, and it is not catching things".

serge-nikulin · 2018-06-28T00:28:52Z

... I'd want to make a distinction...

I guess, 90% would prefer to assert in both cases.
Can you do one call for such dumbed-down case and separate non-terminating calls for the rest 10%?

wjwwood · 2018-06-28T00:40:57Z

I will consider making it the default, but in my opinion it's not as obvious as you portray it.

Almost all of the tests in rcl would not want to fail if memory tools is not active (like on Windows), e.g. this test does lots of stuff and only part of it is related to memory checks:

https://github.com/ros2/rcl/blob/master/rcl/test/rcl/test_node.cpp

It would be equally inconvenient to circumvent the check in all tests like this one.

Also, I don't believe that a majority of people would want memory tools to fail on Windows, where your only workaround is to skip the whole test on Windows.

deeplearningrobotics · 2018-06-28T00:48:58Z

@wjwwood: Thank you for your input. I adapted your function but it does not seem to work.

If I remove the assertion function, memory tools work properly. But when I call the function the lambda on_malloc never gets called. I pushed the non-working code so you could perhaps look at it.

wjwwood · 2018-06-28T00:55:53Z

Not sure, have you setup memory tools before hand? (it won't work if memory tools is uninitialized or if memory checking is not enabled)

Otherwise, perhaps the code in the {} scope is getting optimized out? We found gcc to be pretty aggressive, especially in CMAKE_BUILD_TYPE=Release.

wjwwood · 2018-06-28T01:03:36Z

It seems like you are initializing it correctly. Are the other calls working (like later in your tool)?

wjwwood · 2018-06-28T01:04:43Z

Oh, you said that is was (sorry working on little sleep :p).

I'd see if it's getting optimized out or not. Try adding a print statement in the malloc test function (warning it might cause the check to work, but break again when you remove it).

serge-nikulin · 2018-06-28T01:10:52Z

@wjwwood,

will consider making it the default, but in my opinion it's not as obvious as you portray it.

Yes, you are right and I'm not. How about a checker function that returns:

Everything is OK (zero?)
Error: can't detect a call
Error: OS/environment is not supported
...

wjwwood · 2018-06-28T01:12:22Z

I can do that or have the user give an argument to the "start" function from your example API to dictate the behavior, or I can do both.

I'll be working on the improvements to memory tools tomorrow.

deeplearningrobotics · 2018-06-28T01:15:59Z

@wjwwood: Np, I am glad that you help me! So the malloc_test_function is called but the lambda on_malloc is not. I added a print to both of them.

wjwwood · 2018-06-28T01:17:43Z

Is it that the on_malloc() is getting evaluated in place rather than being deferred to the scope exit?

wjwwood · 2018-06-28T01:20:01Z

No that doesn't seem likely either.

Can you give me (or point me to) some setup instructions for this and I can try it out myself.

deeplearningrobotics · 2018-06-28T01:28:36Z

@wjwwood: I already updated the readme on this branch. so you should be able to follow it. You just need to have memory tools available and run performance test with --check_memory enabled.

wjwwood · 2018-06-28T01:54:10Z

I'll try it out, but it might take me a while.

wjwwood · 2018-06-28T03:39:20Z

Not sure I'll get to this tonight. I'll do my best to look at it tomorrow morning, but while the release is still slowly wrapping up I'm pretty busy.

deeplearningrobotics · 2018-07-09T10:52:03Z

@wjwwood: Could you find the time to look into this issue? Thank you!

wjwwood · 2018-07-09T16:59:25Z

Yup, I'm back at work today, I'll catch up on it.

wjwwood · 2018-07-09T21:44:10Z

@deeplearningrobotics I'm not able to build without the micro dds rmw implementation, is that intentional? I get:

Starting >>> performance_test
--- stderr: performance_test
CMake Warning at CMakeLists.txt:48 (find_package):
  By not providing "Findmicro_dds_cmake_module.cmake" in CMAKE_MODULE_PATH
  this project has asked CMake to find a package configuration file provided
  by "micro_dds_cmake_module", but CMake did not find one.

  Could not find a package configuration file provided by
  "micro_dds_cmake_module" with any of the following names:

    micro_dds_cmake_moduleConfig.cmake
    micro_dds_cmake_module-config.cmake

  Add the installation prefix of "micro_dds_cmake_module" to
  CMAKE_PREFIX_PATH or set "micro_dds_cmake_module_DIR" to a directory
  containing one of the above files.  If "micro_dds_cmake_module" provides a
  separate development package or SDK, be sure it has been installed.


make[2]: *** [src/idlgen/fast_rtps/gen/fast_rtps/Vector3_PubSubTypes.h] Error 1
make[1]: *** [src/idlgen/fast_rtps/CMakeFiles/fast_rtps_idl.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
---
Failed   <<< performance_test	[ Exited with code 2 ]

wjwwood · 2018-07-09T22:02:24Z

/cc @dejanpan

Here's what I'm using:

william@johnnycake:~/apex_ws/src/ApexAI/performance_test (git:master:ee89af5)
$ git log -1
commit ee89af590f432c6bfd972358ce3c7f3f4292a4c2 (HEAD -> master, origin/master, origin/HEAD)
Merge: a5c1db5 5e08340
Author: Dejan Pangercic <dejan.pangercic@gmail.com>
Date:   Sat Jun 16 00:00:55 2018 -0700

    Merge pull request #1 from andreaspasternak/documentation_improvements

    Documentation improvements

william@johnnycake:~/apex_ws/src/ApexAI/performance_test (git:master:ee89af5)
$ git remote -v
origin	git@github.com:ApexAI/performance_test.git (fetch)
origin	git@github.com:ApexAI/performance_test.git (push)

dejanpan · 2018-07-10T00:42:32Z

@wjwwood
the "error" pasted above is actually just a warning and the compilation should proceed normally even if Connext DDS Micro is not found.

The actual error is further down:

In file included from /home/dejan.pangercic/1578/apex_ws/build/performance_test/src/idlgen/fast_rtps/gen/fast_rtps/Time_PubSubTypes.cxx:26:0:
/home/dejan.pangercic/1578/apex_ws/build/performance_test/src/idlgen/fast_rtps/gen/fast_rtps/Time_PubSubTypes.h: At global scope:
/home/dejan.pangercic/1578/apex_ws/build/performance_test/src/idlgen/fast_rtps/gen/fast_rtps/Time_PubSubTypes.h:48:41: error: ‘SerializedPayload_t’ has not been declared
              bool serialize(void *data, SerializedPayload_t *payload);
                                         ^
/home/dejan.pangercic/1578/apex_ws/build/performance_test/src/idlgen/fast_rtps/gen/fast_rtps/Time_PubSubTypes.h:49:31: error: ‘SerializedPayload_t’ has not been declared
              bool deserialize(SerializedPayload_t *payload, void *data);
                               ^
/home/dejan.pangercic/1578/apex_ws/build/performance_test/src/idlgen/fast_rtps/gen/fast_rtps/Time_PubSubTypes.h:51:38: error: ‘InstanceHandle_t’ has not been declared
              bool getKey(void *data, InstanceHandle_t *ihandle);

and for that I suspect that the bundled version of fastrtpsgen is out of date: https://github.com/ApexAI/performance_test/tree/memory_check/performance_test/bin.

I am looking into this.

dejanpan · 2018-07-10T00:56:19Z

@wjwwood update:
both master and memory_check branches compile with Ardent.

I am now looking into why Bouncy fails. It must be a change in fastRTPS.

serge-nikulin · 2018-07-20T08:27:17Z

Documentation bug:

$ source ros2_install_path/local_setup.bash
-bash: ros2_install_path/local_setup.bash: No such file or directory

The Readme should explain how to get actual folder instead of ros2_install_path placeholder

serge-nikulin · 2018-07-20T08:30:10Z

Documentation bug:

No current directory defined.

mkdir -p perf_test_ws/src

What if my pwd is /?

serge-nikulin · 2018-07-20T08:34:23Z

Documentation bug:

$ source ~/ros2_install/local_setup.bash
-bash: ~/ros2_install/local_setup.bash: No such file or directory

The local_setup.bash file is not in the ros2_install folder.

serge-nikulin · 2018-07-20T08:38:19Z

~~Installation or Documentation bug?~~

~~By following the installation procedure I have installed ROS 2 Bouncy.~~

~~Bouncy does not have ament~~

~~Full stop here.~~

serge-nikulin · 2018-07-20T08:43:17Z

Scratch the previous comment. My bash had an alias for ament.

serge-nikulin · 2018-07-20T08:45:44Z

Documentation error: no prerequisite requirement for JDK.

The build failed:

+++ Building 'performance_test'
==> '. /Users/snikulin/src/perf_test_ws/build/performance_test/cmake__build.sh && /usr/bin/make -j4 -l4' in '/Users/snikulin/src/perf_test_ws/build/performance_test'
Java binary cannot be found. Please, make sure its location is in the PATH environment variable or set JAVA_HOME environment variable.
make[2]: *** [src/idlgen/fast_rtps/gen/fast_rtps/Vector3_PubSubTypes.h] Error 1
make[1]: *** [src/idlgen/fast_rtps/CMakeFiles/fast_rtps_idl.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[  1%] Built target performance_test__py
[  1%] Built target performance_test__cpp
[ 10%] Built target performance_test__rosidl_generator_c
make: *** [all] Error 2

serge-nikulin · 2018-07-20T08:58:21Z

Multiple build errors, seems of two kinds only:

In file included from ~/src/perf_test_ws/build/performance_test/src/idlgen/fast_rtps/gen/fast_rtps/Header_PubSubTypes.cxx:26:
~/src/perf_test_ws/build/performance_test/src/idlgen/fast_rtps/gen/fast_rtps/Header_PubSubTypes.h:48:41: error: unknown type name 'SerializedPayload_t'; did you mean
      'eprosima::fastrtps::rtps::SerializedPayload_t'?
                bool serialize(void *data, SerializedPayload_t *payload);
                                           ^~~~~~~~~~~~~~~~~~~
                                           eprosima::fastrtps::rtps::SerializedPayload_t

and

In file included from ~/src/perf_test_ws/build/performance_test/src/idlgen/fast_rtps/gen/fast_rtps/Header_PubSubTypes.cxx:26:
~/src/perf_test_ws/build/performance_test/src/idlgen/fast_rtps/gen/fast_rtps/Header_PubSubTypes.h:51:38: error: unknown type name 'InstanceHandle_t'; did you mean
      'eprosima::fastrtps::rtps::InstanceHandle_t'?
                bool getKey(void *data, InstanceHandle_t *ihandle);
                                        ^~~~~~~~~~~~~~~~
                                        eprosima::fastrtps::rtps::InstanceHandle_t

serge-nikulin · 2018-07-20T09:08:15Z

Looks like a legit bug to me: the header file contains

using namespace eprosima::fastrtps;

But no reference to ::rtps namespace.

Here is the full contents of ~/src/perf_test_ws/build/performance_test/src/idlgen/fast_rtps/gen/fast_rtps/Header_PubSubTypes.h

// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

/*! 
 * @file Header_PubSubTypes.h
 * This header file contains the declaration of the serialization functions.
 *
 * This file was generated by the tool fastcdrgen.
 */


#ifndef _HEADER__PUBSUBTYPES_H_
#define _HEADER__PUBSUBTYPES_H_

#include <fastrtps/TopicDataType.h>

using namespace eprosima::fastrtps;

#include "Header_.h"

namespace std_msgs
{
    namespace msg
    {
        namespace dds_
        {
            /*!
             * @brief This class represents the TopicDataType of the type Header_ defined by the user in the IDL file.
             * @ingroup HEADER_
             */
            class Header_PubSubType : public TopicDataType {
            public:
                    typedef Header_ type;

                Header_PubSubType();
                virtual ~Header_PubSubType();
                bool serialize(void *data, SerializedPayload_t *payload);
                bool deserialize(SerializedPayload_t *payload, void *data);
                    std::function<uint32_t()> getSerializedSizeProvider(void* data);
                bool getKey(void *data, InstanceHandle_t *ihandle);
                void* createData();
                void deleteData(void * data);
                MD5 m_md5;
                unsigned char* m_keyBuffer;
            };
        }
    }
}

#endif // _Header__PUBSUBTYPE_H_

deeplearningrobotics · 2018-07-24T12:07:21Z

@serge-nikulin: I updated the readme for bouncy and fixed some defects and tested the code on the following platforms:

Ubuntu 18.04
Ubuntu 16.04
ADE Intel
ADE ARM

I think the README is reasonable to follow for a user with very basic ROS knowledge.
You do not need JAVA as fastrtpsgen.jar is bundled for bouncy now.

Please test in ADE or Ubuntu to not run into independent systems.

wjwwood

Reviewed 6 of 9 files at r1, 1 of 2 files at r3, 2 of 2 files at r4.
Reviewable status: 7 of 11 files reviewed, 5 unresolved discussions (waiting on @wjwwood and @serge-nikulin)

wjwwood

Reviewed 4 of 4 files at r5.
Reviewable status: all files reviewed, 5 unresolved discussions (waiting on @serge-nikulin)

serge-nikulin · 2018-07-26T19:15:15Z

@deeplearningrobotics,

Out of curiosity, why do you use float64 for the timestamp?
By going from 64-bit ROS-like nanosecond timestamp to 53-bit mantissa of float64 you are essentially dropping both resolution and precision by more than 3 orders of magnitude to few microseconds range (that's assuming steady_clock gives you nanoseconds).

One usually goes to floats (from integers) when one needs dynamic range at the price of precision and resolution. It seems to me in this case timestamps do not need a wide dynamic range ([0 ... 10] sec?) but need both precision and resolution.

serge-nikulin · 2018-07-26T19:18:42Z

long double has at least 64-bit mantissa and won't worsen your timestamps.
See https://en.wikipedia.org/wiki/Long_double#Other_specifications

deeplearningrobotics · 2018-07-26T21:22:11Z

@serge-nikulin: I could not use any built-in time types, I wanted to use long double but it is not available as a ROS 2 type. I did some research and I think you a right that this could have influences on measurement accuracy. Switching to uint64 would solve this problem, yes? Internally I could do calculations then with long double.

serge-nikulin · 2018-07-26T21:28:01Z

Yes, using uint64 as a transport and long double during computations should fix the problem with the minimal changes.

serge-nikulin · 2018-07-27T19:36:27Z

Do you intend to use your program across different boxes?

In this case, you can't use std::chrono::steady_clock for timestamping.

See https://en.cppreference.com/w/cpp/chrono/steady_clock:

This clock is not related to wall clock time (for example, it can be time since last reboot), and is most suitable for measuring intervals.

Because the clock does not have a universal reference point (like wall clock does), it can't be used across machines (including VM) and even processes on a well secured OS (they isolate and salt such timers to prevent crypto leaks).

Steady clock timer value would be different and unrelated on different machines (including VM).

Because we do not care, our ADE possibly leaks steady timers across containers, but this is a bug (of Docker?), not a feature to take for granted.

deeplearningrobotics · 2018-07-27T20:32:37Z

@serge-nikulin: You are right. As you always want to use a steady clock in robotics the use of a steady clock here is appropriate, IMHO. If people want to test between processes without a common steady clock (because of different physical or logical machines) then one could add:

The option to select a different clock.
The option to measure round trip.

But this is then part of another feature.

serge-nikulin · 2018-07-27T23:22:11Z

Please add this restriction to the document, otherwise people will measure inter box time and get wrong results. It would be nice to stop such attempts automatically.

…

On Fri, Jul 27, 2018 at 10:32 AM deeplearningrobotics < ***@***.***> wrote: @serge-nikulin <https://github.com/serge-nikulin>: As you always want to use a steady clock in robotics the use of a steady clock here is appropriate. If people want to test between processes without a common steady clock (because of different physical or logical machines) then one could add: - The option to select a different clock. - The option to measure round trip. But this is then part of another feature. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AeCfXXyfJXyOczCiC275uU9rDeTc0O5fks5uK3jlgaJpZM4U6c1X> .

serge-nikulin · 2018-08-02T18:19:35Z

Because this app is Linux-only and my forte is OS X and Windows, I assume somebody else has actually built and ran it in Linux (I could not: can't install ROS2).

serge-nikulin

Because this app is Linux-only and my forte is OS X and Windows, I assume somebody else has actually built and ran it in Linux (I could not: can't install ROS2).

serge-nikulin · 2018-06-28T00:01:51Z

performance_test/src/data_running/data_runner_base.hpp

@@ -51,7 +51,6 @@ class DataRunnerBase : boost::noncopyable

      auto on_unexpected_memory =
              [](osrf_testing_tools_cpp::memory_tools::MemoryToolsService &service) {


This will be hard to decipher.

deeplearningrobotics · 2018-08-02T19:31:37Z

@serge-nikulin: Thank you, I will create an issue for the clock and time-related issues you mentioned and fix them in a seperate MR..

wjwwood · 2018-10-12T21:19:39Z

There's now a function to check if memory tools is working or not:

osrf/osrf_testing_tools_cpp#16

deeplearningrobotics force-pushed the memory_check branch from 6446f03 to 808445e Compare June 27, 2018 23:16

dejanpan assigned dejanpan and serge-nikulin and unassigned dejanpan Jun 27, 2018

serge-nikulin suggested changes Jun 27, 2018

View reviewed changes

deeplearningrobotics force-pushed the memory_check branch from 2d6e80c to df4fa16 Compare June 28, 2018 00:08

deeplearningrobotics mentioned this pull request Jul 5, 2018

Enable ROS 2 and FastRTPS in parallel for Bouncy #4

Closed

Andreas Pasternak added 5 commits July 23, 2018 15:47

Updated fastrtpsgen for bouncy.

bc58a32

Added workaround for broken include paths.

7a44c94

Updated and fixed installation documentation.

ebb6a8f

Enabled FastRTPS and ROS 2 at the same time.

ef1913c

Fixed minor issue in installation instruction.

7c56833

wjwwood reviewed Jul 24, 2018

View reviewed changes

serge-nikulin approved these changes Aug 2, 2018

View reviewed changes

deeplearningrobotics merged commit 4ccab61 into master Aug 2, 2018

deeplearningrobotics mentioned this pull request Aug 2, 2018

ROS 2 FastRTPS fastrtpsddsgen is broken under Ubuntu 18.04 #7

Closed

deeplearningrobotics deleted the memory_check branch November 22, 2018 15:54

		@@ -51,7 +51,6 @@ class DataRunnerBase : boost::noncopyable

		auto on_unexpected_memory =
		[](osrf_testing_tools_cpp::memory_tools::MemoryToolsService &service) {

Added the possibility to check the used middleware for memory operations. #2

Added the possibility to check the used middleware for memory operations. #2

Conversation

deeplearningrobotics commented Jun 27, 2018 • edited by dejanpan Loading

dejanpan commented Jun 27, 2018

wjwwood commented Jun 27, 2018

serge-nikulin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

serge-nikulin Jun 27, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wjwwood commented Jun 28, 2018

serge-nikulin commented Jun 28, 2018

wjwwood commented Jun 28, 2018

deeplearningrobotics commented Jun 28, 2018

wjwwood commented Jun 28, 2018

wjwwood commented Jun 28, 2018

wjwwood commented Jun 28, 2018

serge-nikulin commented Jun 28, 2018

wjwwood commented Jun 28, 2018

deeplearningrobotics commented Jun 28, 2018

wjwwood commented Jun 28, 2018

wjwwood commented Jun 28, 2018

deeplearningrobotics commented Jun 28, 2018

wjwwood commented Jun 28, 2018

wjwwood commented Jun 28, 2018

deeplearningrobotics commented Jul 9, 2018

wjwwood commented Jul 9, 2018

wjwwood commented Jul 9, 2018

wjwwood commented Jul 9, 2018

dejanpan commented Jul 10, 2018

dejanpan commented Jul 10, 2018

serge-nikulin commented Jul 20, 2018

serge-nikulin commented Jul 20, 2018

serge-nikulin commented Jul 20, 2018

serge-nikulin commented Jul 20, 2018 • edited Loading

serge-nikulin commented Jul 20, 2018

serge-nikulin commented Jul 20, 2018 • edited Loading

serge-nikulin commented Jul 20, 2018

serge-nikulin commented Jul 20, 2018

deeplearningrobotics commented Jul 24, 2018

wjwwood left a comment

Choose a reason for hiding this comment

wjwwood left a comment

Choose a reason for hiding this comment

serge-nikulin commented Jul 26, 2018 • edited Loading

serge-nikulin commented Jul 26, 2018

deeplearningrobotics commented Jul 26, 2018

serge-nikulin commented Jul 26, 2018

serge-nikulin commented Jul 27, 2018

deeplearningrobotics commented Jul 27, 2018 • edited Loading

serge-nikulin commented Jul 27, 2018 via email

serge-nikulin commented Aug 2, 2018

serge-nikulin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

deeplearningrobotics commented Aug 2, 2018

wjwwood commented Oct 12, 2018

deeplearningrobotics commented Jun 27, 2018 •

edited by dejanpan

Loading

serge-nikulin Jun 27, 2018 •

edited

Loading

serge-nikulin commented Jul 20, 2018 •

edited

Loading

serge-nikulin commented Jul 20, 2018 •

edited

Loading

serge-nikulin commented Jul 26, 2018 •

edited

Loading

deeplearningrobotics commented Jul 27, 2018 •

edited

Loading