Conflict with compressed_image_transport

[shuntaraw]

Describe the bug
A node crashes when compressed color/depth stream is subscribed.

To Reproduce
Steps to reproduce the behavior:

1. Install compressed_image_transport:

sudo apt-get install ros-melodic-compressed-image-transport

2. Run a ROS node:

roslaunch azure_kinect_ros_driver driver.launch

3. Subscribe to one of compressed streams:

rostopic hz /rgb/image_raw/compressed

4. See error:

[node-1] process has died [pid 25048, exit code -11, cmd ...

Expected behavior
Subscription works.

Logs
See above.

Desktop (please complete the following information):

• OS: Ubuntu
• Version 18.04

Additional context
The node crashes at cv::imencode() in CompressedPublisher::advertiseImpl:
https://github.com/ros-perception/image_transport_plugins/blob/indigo-devel/compressed_image_transport/src/compressed_publisher.cpp#L137

The reason of the crash is that the version of libjpeg-turbo statically linked to libk4a is incompatible with the version of the same library dynamically loaded in libopencv_imgcodecs. It seems something similar happens in #37.

[shuntaraw]

A tentative workaround is as follows:

1. Disable image_transport in azure_kinect_ros_driver/node, e.g. in a launch file,

  <rosparam ns="rgb/image_raw" param="disable_pub_plugins" >
    - 'image_transport/compressed'
    - 'image_transport/compressedDepth'
  </rosparam>
 :

2. Republish the raw stream with compression, e.g. in a launch file,

 <node ns="rgb" name="compressed_rgb" pkg="image_transport" type="republish" args="raw in:=image_raw compressed out:=image_raw"/>
 :

[skalldri]

This is fantastic: thanks for digging into this issue. I won't have time this week to look into it, but this will be a great help in repro-ing the issue.

[skalldri]

Never mind, this ended up at the top of my work queue today. I did some deep diving.

I crashed the node intentionally under GDB to see what's going on.

(gdb) backtrace
#0 0x00007ffff7b0b4e5 in jpeg_CreateCompress (cinfo=0x7fff5fffd5b0, version=80, structsize=584) at /home/vsts/work/1/s/extern/Azure-Kinect-Sensor-SDK/extern/libjpeg-turbo/src/jcapimin.c:41
#1 0x00007fffde35a82c in ?? () from /usr/lib/x86_64-linux-gnu/libopencv_imgcodecs.so.3.2
#2 0x00007fffde34d45c in cv::imencode(cv::String const&, cv::InputArray const&, std::vector<unsigned char, std::allocator >&, std::vector<int, std::allocator > const&) () from /usr/lib/x86_64-linux-gnu/libopencv_imgcodecs.so.3.2
#3 0x00007fffc2650a9d in ?? () from /opt/ros/melodic/lib//libcompressed_image_transport.so
#4 0x00007fffc265644e in ?? () from /opt/ros/melodic/lib//libcompressed_image_transport.so
#5 0x00007ffff752254d in image_transport::Publisher::publish(boost::shared_ptr<sensor_msgs::Image<std::allocator > const> const&) const () from /opt/ros/melodic/lib/libimage_transport.so
#6 0x0000555555566905 in K4AROSDevice::framePublisherThread() ()
#7 0x000055555557391c in void std::__invoke_impl<void, void (K4AROSDevice::)(), K4AROSDevice>(std::__invoke_memfun_deref, void (K4AROSDevice::&&)(), K4AROSDevice&&) ()
#8 0x000055555556eadf in std::__invoke_result<void (K4AROSDevice::)(), K4AROSDevice>::type std::__invoke<void (K4AROSDevice::)(), K4AROSDevice>(void (K4AROSDevice::&&)(), K4AROSDevice&&) ()
#9 0x000055555557cc2b in decltype (__invoke((_S_declval<0ul>)(), (_S_declval<1ul>)())) std::thread::_Invoker<std::tuple<void (K4AROSDevice::)(), K4AROSDevice> >::_M_invoke<0ul, 1ul>(std::_Index_tuple<0ul, 1ul>) ()
#10 0x000055555557cbcc in std::thread::_Invoker<std::tuple<void (K4AROSDevice::)(), K4AROSDevice> >::operator()() ()
#11 0x000055555557cb80 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (K4AROSDevice::)(), K4AROSDevice> > >::_M_run() ()
#12 0x00007ffff633166f in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#13 0x00007ffff66046db in start_thread (arg=0x7fff5ffff700) at pthread_create.c:463
#14 0x00007ffff59ee88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

See highlighted frames. This is wrong: based on the OpenCV source code, it should be calling into libjpeg.so.8, not libk4a. Ok, so lets check the loaded shared libraries:

(gdb) info sharedlibrary
From To Syms Read Shared Object Library
...
0x00007ffff7ac2aa0 0x00007ffff7b74225 Yes /usr/lib/x86_64-linux-gnu/libk4a.so.1.2
0x00007ffff77c3940 0x00007ffff7848f1c Yes /usr/lib/x86_64-linux-gnu/libk4arecord.so.1.2
....
0x00007fffdd745e10 0x00007fffdd77f7a0 Yes () /usr/lib/x86_64-linux-gnu/libjpeg.so.8
....
0x00007fffde348bb0 0x00007fffde36abbe Yes () /usr/lib/x86_64-linux-gnu/libopencv_imgcodecs.so.3.2

Ok... all the right shared libs are loaded, so why is it picking the wrong symbol still?

Lets look in libk4a:

objdump -t /usr/lib/x86_64-linux-gnu/libk4a.so.1.2 | grep jpeg_CreateDecompress
000000000007dfb0 g F .text 0000000000000136 jpeg_CreateDecompress

Ah ha. This symbol should be marked with visbility=hidden to prevent this kind of conflict, and indeed this should have been fixed by microsoft/Azure-Kinect-Sensor-SDK#651. However, it's still not hidden in the binaries that are published as part of the 1.2 SDK, so something has gone wrong. Digging deeper.

[tabula-rosa]

A tentative workaround is as follows:

1. Disable image_transport in `azure_kinect_ros_driver/node`, e.g. in a launch file,

  <rosparam ns="rgb/image_raw" param="disable_pub_plugins" >
    - 'image_transport/compressed'
    - 'image_transport/compressedDepth'
  </rosparam>
 :

1. Republish the raw stream with compression, e.g. in a launch file,

 <node ns="rgb" name="compressed_rgb" pkg="image_transport" type="republish" args="raw in:=image_raw compressed out:=image_raw"/>
 :

Thank you for providing this workaround. This worked for me for subscribing to compressed RGB images. However, it does not appear to work for compressed depth images. When subscribing to the compressed depth topic, I receive the following error and nothing is published: Compressed Image Transport - JPEG compression requires 8/16-bit color format (input format is: 32FC1)

[skalldri]

You need to use compressed_depth_image_transport to compress depth images.

[skalldri]

Root caused to an issue in the Azure Kinect Sensor SDK. This will be fixed when microsoft/Azure-Kinect-Sensor-SDK#672 is fixed.

[ooeygui]

This bug was dependent on an SDK change which was corrected.