resolve memory leak for serialized message

[Karsten1987]

addressed #499

as stated in #499 (comment), the change to rclcpp::SerializedMessage introduced this regression in which we transfer ownership, the smart pointer however doesn't cleanup the transferred memory. Specifically this change here:
https://github.com/ros2/rosbag2/pull/386/files#diff-1a63843318260f13eda07d98c90c9c66L107-L116

[Karsten1987]

build up to rosbag2, testing rosbag2_tests, rosbag2_transport

• Linux
• Linux-aarch64
• macOS
• Windows

[dawonn-haval]

I think you forgot to allocate 'msg'.

I got a segfault with this PR, so I copied a snippet from elsewhere and it seems to run without leaking:

      auto msg = new rcutils_uint8_array_t;
      *msg = rcutils_get_zero_initialized_uint8_array();

      bag_message->serialized_data = std::shared_ptr<rcutils_uint8_array_t>(
        msg,
        [](rcutils_uint8_array_t * msg) {
            int error = rcutils_uint8_array_fini(msg);
            delete msg;
            if (error != RCUTILS_RET_OK) {
              RCUTILS_LOG_ERROR_NAMED("rosbag2_transport", "Recorder::create_subscription leaking memory %i", error);
        }
        });
      *bag_message->serialized_data = message->release_rcl_serialized_message();

[Karsten1987]

Thanks for given it a shot. Can you post a backtrace or explain what you've ran to provoke the segfault?
It worked as-is on my machine with valgrind reporting improvements in terms of heap usage.

[dawonn-haval]

I simply tried recording topics, any topics, all topics immediately segfault as soon as they process the first message. I do not know how to run ros2 commands in gdb, if you could point me in the right direction I would be happy to get you a bt. I assume that the seg fault in the unit test failures are of the same cause? https://ci.ros2.org/job/ci_linux/11862/testReport/junit/(root)/projectroot/test_rosbag2_record_end_to_end/

[Karsten1987]

my bad, this should be fixed now.

[emersonknapp]

This LGTM, but a comment explaining why it's necessary may be helpful

[Karsten1987]

• Linux
• Linux-aarch64
• macOS
• Windows

[clalancette]

I suspect that this PR is the cause of a regression on the buildfarm last night: https://ci.ros2.org/view/nightly/job/nightly_linux_debug/1664/testReport/junit/(root)/projectroot/test_record_all_no_discovery__rmw_fastrtps_cpp/ . It's not immediately obvious to me why, but it is in the correct area and its the only rosbag2 change from yesterday.