IDS Ueye 4.92 munmap_chunk invalid pointer in ros::init

[devrite]

Hi everyone!

We used a ros:melodic-perception-bionic the docker image (with the necessary dependencies installed):

#Digest: sha256:2a8412596201e7be8a181f4523d00446f6e0a37e659eee4f6a2898139d11972a

docker pull ros:melodic-perception-bionic
docker run --rm --name ids-4.92-ros-error -v$HOME/Downloads/ueye_4.92.0.0_amd64.run:/ueye_4.92.0.0_amd64.run:ro -it  ros:melodic-perception-bionic

apt-get update && apt-get upgrade
apt-get -y install wget software-properties-common build-essential wget curl cmake git rsync gdb

/ueye_4.92.0.0_amd64.run
mkdir /build
cd /build
git clone https://github.com/anqixu/ueye_cam.git
cd ueye_cam
mkdir debug
cd debug
cmake -DCMAKE_BUILD_TYPE=Debug ..
make -j4
source devel/setup.bash
rosrun ueye_cam check_ueye_api

Using gdb and catch throw you may print a backtrace (error in ros::init -> file log).

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007fc255fda801 in __GI_abort () at abort.c:79
#2  0x00007fc256023897 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fc256150b9a "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007fc25602a90a in malloc_printerr (str=str@entry=0x7fc2561527a8 "munmap_chunk(): invalid pointer") at malloc.c:5350
#4  0x00007fc256031ecc in munmap_chunk (p=0x55a6778ba5a0) at malloc.c:2846
#5  __GI___libc_free (mem=0x55a6778ba5b0) at malloc.c:3117
#6  0x00007fc2579595d0 in ros::file_log::init(std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > const&) ()
   from /opt/ros/melodic/lib/libroscpp.so
#7  0x00007fc257981821 in ros::init(std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int) () from /opt/ros/melodic/lib/libroscpp.so
#8  0x00007fc25798416c in ros::init(int&, char**, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int) () from /opt/ros/melodic/lib/libroscpp.so
#9  0x000055a677146345 in main (argc=1, argv=0x7ffc53e989a8) at /build/ueye_cam/src/check_ueye_api.cpp:45

Best regards,

Markus

[devrite]

Using lldb (the container needs to be started with --privileged as it needs special kernel features for debugging otherwise running of the program fails using lldb):

lldb devel/lib/ueye_cam/check_ueye_api
(lldb) break set --name ros::init
(lldb) run
(lldb) break delete 1
(lldb) break set -r . -s libueye_api.so.1
(lldb) c
(lldb) bt

It looks like ros::init jumps into the ueye implementations of boost stuff (especially filesystem stuff). So there might be a version conflict in the used boost versions, which are exported by ueye (static linked exported boost).

Output:

* thread #1, name = 'check_ueye_api', stop reason = breakpoint 4.191
  * frame #0: 0x00007ffff715d270 libueye_api.so.1`boost::filesystem::detail::create_directory(boost::filesystem::path const&, boost::system::error_code*)
    frame #1: 0x00007ffff793dc58 libroscpp.so`ros::file_log::init(std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > const&) + 3656
    frame #2: 0x00007ffff7965821 libroscpp.so`ros::init(std::map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int) + 145
    frame #3: 0x00007ffff796816c libroscpp.so`ros::init(int&, char**, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int) + 940
    frame #4: 0x0000555555555345 check_ueye_api`main(argc=1, argv=0x00007fffffffe418) at check_ueye_api.cpp:45
    frame #5: 0x00007ffff5f9fb97 libc.so.6`__libc_start_main(main=(check_ueye_api`main at check_ueye_api.cpp:37), argc=1, argv=0x00007fffffffe418, init=<unavailable>, fini=<unavailable>, rtld_fini=<unavailable>, stack_end=0x00007fffffffe408) at libc-start.c:310
    frame #6: 0x0000555555554fda check_ueye_api`_start + 42

[loooph]

Might be late but i had the same issue and have resolved it in #77 .

[devrite]

Sorry, I checked today. It was being linked. The issue still remains in other context where the library is not being loaded at runtime dynamically (in the nodelet context it will be, hence it works, right now ...).

For check_ueye_api the issue is solved by not linking it as you suggest. But for any node that uses the library via build time linking will fail as check_ueye_api.

It will only be resolvable if ueye_api is being rebuilt by IDS so that it does not export any thirdparty symbols if they are not used in the interface.

[ChrisSchulte]

Hi everyone,

I'm having the same troubles with ROS Kinetic on Ubuntu 16.04 LTS with IDS SDK version 4.91.1. Same behaviour as above, a munmap_chunk() : invalid pointer crash as soon as a build time link with the ueye_api exists, even if no call to any ueye function is made in the executable. Every executable using ueye without libroscpp.so works flawlessly.

Chris

[Simen-Thys]

Perhaps we could use Implib.so to hide the unnecessary boost symbols. I haven't tested this myself though.