image_view: Attempt to unlock mutex that was not locked

[abhinavkssk]

Hi,

When I try to visualize an image using the image_view node and i get:

Attempt to unlock mutex that was not locked
Aborted

There were previous issues (#106) and (#153) but none seem to have a solution

Any clue?

My ROS version is Indigo on Arch Linux.

Thanks in advance.

[vrabaud]

Looking online, it seems like a GTK bug: https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=fbf38d16bcc26630f0f721d266509f5bc292f606
Which OpenCV and GTK are you using ? Can't you compile with Qt ? (I don't know if arch allows that).

Otherwise, go with rqt_image_view, it will not have that bug.

[abhinavkssk]

Thanks for the help!

Using OpenCV 3.1 and have got both GTK+ 3 and 2 installed - But from the CMake file for image_view I can see that it's linking against GTK2 specifically

When you say compile against Qt - do you mean to compile image_view with qt ?

[vrabaud]

image_view does not link to GTK, only the nodelet (which got removed from image_view for that kind of issue).

[abhinavkssk]

I'm not very familiar with how nodelets work, but doesn't the following excerpt from the CMake file imply that image_view executable is indeed linking against the gtk libraries?

add_library(image_view src/nodelets/image_nodelet.cpp src/nodelets/disparity_nodelet.cpp src/nodelets/window_thread.cpp)
target_link_libraries(image_view ${catkin_LIBRARIES}
                                 ${GTK_LIBRARIES}
                                 ${GTK2_LIBRARIES}
                                 ${OpenCV_LIBRARIES}
                                 ${Boost_LIBRARIES}
)
install(TARGETS image_view
        DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION}
)

[vrabaud]

It's confusing but that is the line to look at:
https://github.com/ros-perception/image_pipeline/blob/indigo/image_view/CMakeLists.txt#L58

[vrabaud]

So you are still having problems with the executable alone ? (if you do an ldd on it, do you see any GTK lib ?)

[abhinavkssk]

Yes, the image_view is still failing with the same error and it does seem to be linking against gtk3.0

ldd image_view |grep gtk
    libgtk-3.so.0 => /usr/lib/libgtk-3.so.0 (0x00007f22beb73000)

[vrabaud]

interesting, so it really is because of your platform. Can you check to which libopencv_highgui3 you are linked to and if it is linked to gtk (mine is not as we force OpenCV to be linked to Qt but maybe not on your platform).

[abhinavkssk]

Yes, this does seem to be the case. I didn't think that the gtk dependency could've been inherited from opencv itself !

ldd libopencv_highgui.so.3.1 |grep gtk
    libgtk-3.so.0 => /usr/lib/libgtk-3.so.0 (0x00007f0c620f9000)

So, I assume recompiling opencv with Qt might fix this particular issue?

[vrabaud]

yes. If you have Qt and use the official opencv3-release (if you use the standard compilation from source from ROS), then you should be fine:
https://github.com/ros-gbp/opencv3-release/blob/release/kinetic/opencv3/CMakeLists.txt#L196

[vrabaud]

Hi, closing as we established that this is (unfortunately) a bug in how OpenCV uses GTK. We can continue the discussion here though to help you out with Qt.

[roehling]

This bug seems to have resurfaced with Ubuntu 18.04 / ROS Melodic, since they use the system OpenCV library.

[roehling]

Inspired by this Stackoverflow entry, I managed to fix the crash by removing the call to cv::startWindowThread().

A good workaround for the buggy GTK thread implementation is a ros::Timer that calls cv::waitKey() periodically.

I can prepare a PR if you want.

[kunaltyagi]

PR would be appreciated. If only so others can compile and get it working again. Can you provide a minimal example of the bug without ROS also? I can try to follow up with OpenCV community.

[roehling]

The minimal example would be

#include <opencv2/highgui/highgui.hpp>

int main (int argc, char** argv)
{
    cv::startWindowThread();
    cv::waitKey(0);
    return 0;
}

Store as opencv_bug.cpp, compile with g++ opencv_bug.cpp -lopencv_highgui, and run the resulting a.out binary.

[kunaltyagi]

Thanks @roehling . Tested your PR, works like a charm.

[AmeyHande]

Hello Timo Roehling (@roehling) ,
Can you tell me a detailed procedure or some reference documentation of how can I implement the solution which you have suggested ?
I'm totally new to this kind of error handling.
I'm trying to run the command rosrun image_view image_view image:=/detection_image and it's giving me this error (detection_image:9729): GLib-GObject-CRITICAL **: 16:40:26.480: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Attempt to unlock mutex that was not locked
Any help from others as well would be greatly appreciated, as I'm stucked mid-way of inspecting one algorithm in ros environment.

[kunaltyagi]

Hi @AmeyHande

1. You'd need to clone this repository (using git) in your catkin workspace (link to tutorial)

git clone https://github.com/ros-perception/image_pipeline.git

2. In the terminal (or any git GUI client that supports the following) fetch the PR to a local branch and change to it. For the terminal:

git -C image_pipeline fetch origin pull/343/head:mutex_error_resolve
git -C image_pipeline checkout mutex_error_resolve

3. Compile the workspace as you usually do (using catkin_make or catkin_make_isolated with the relevant options) (link to tutorial)

roscd; cd ..; catkin_make

4. Done! You can now use image_view as you usually do.

[SandaruCooray]

hi @kunaltyagi
I am new to ROS and Gazebo i am following some tutorial in tutorial in here i am stuck on your problem which is you already solved, could you tell how to implement the solution for this issue
Thank you.

[roehling]

The tutorial seems to clone a full workspace. This means you should probably do something like this:

cd mybot_ws
git -C src clone https://github.com/ros-perception/image_pipeline.git
git -C src/image_pipeline fetch origin pull/343/head:bugfix
git -C src/image_pipeline checkout bugfix
catkin_make

[SandaruCooray]

Thanks @roehling Its working thank you so much 💯

[vidyasudevan]

Hi @kunaltyagi,
Thanks for the solution. It works for me. But when I run image_view again after restarting the system, the same error appears.

[kunaltyagi]

@vidyasudevan If the fix works manually but not on reboot, the most common reason is if your ~/pilab_ws/devel/setup.bash (or related setup shell file) has not been loaded.

1. Please ensure that your rc file (eg: ~/.bashrc) contains the source ~/pilab_ws/deve/setup.bash or . ~/pilab_ws/deve/setup.bash
2. It is not overshadowed by another source of some other workspace or the root ROS setup script (/opt/ros/<distro>/setup.bash is the default location)

[vidyasudevan]

Thanks for the reply

…

On Mon, Dec 10, 2018 at 5:15 AM Kunal Tyagi ***@***.***> wrote: @vidyasudevan <https://github.com/vidyasudevan> If the fix works manually but not on reboot, the most common reason is if your ~/pilab_ws/devel/setup.bash (or related setup shell file) has not been loaded. 1. Please ensure that your rc file (eg: ~/.bashrc) contains the source ~/pilab_ws/deve/setup.bash or . ~/pilab_ws/deve/setup.bash 2. It is not overshadowed by another source of some other workspace or the root ROS setup script (/opt/ros/<distro>/setup.bash is the default location) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#201 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWWBQ5dIqT5urHnNqPTYcGYINVYm6nRqks5u3bWVgaJpZM4IzaQj> .

-- Regards, Vidya Research Assistant Department of Mechanical Engineering The Petroleum Institute Abu Dhabi, UAE

[26atul05]

The tutorial seems to clone a full workspace. This means you should probably do something like this:

cd mybot_ws
git -C src clone https://github.com/ros-perception/image_pipeline.git
git -C src/image_pipeline fetch origin pull/343/head:bugfix
git -C src/image_pipeline checkout bugfix
catkin_make

@roehling
Hello, I followed the steps and got this error in catkin_make. Please guide me in troubleshooting.

[roehling]

This looks like it could be a version conflict with OpenCV. Did you install a different version than the default, or did you update your OpenCV without rebuilding the whole workspace?

[26atul05]

I'm not sure if it's a default version, I downloaded 3.4.5 version and then followed a video on YouTube which made a build using CMake software. After making the build, I just built the workspace by "make" command. I'm new at this so I'm not sure how it works though.

Here's the link to that instruction video:
https://youtu.be/_pB1pJF8nPk

[roehling]

The prebuilt ROS packages link against OpenCV 3.2.0, since that's the version that ships with in Ubuntu 18.04 (the "default" or "system" version for that Ubuntu). It is nearly impossible to mix and match different versions in the same source tree, as you just saw. Either you should stick with the system OpenCV or build ROS completely from source and be extra careful to never accidentally link against the wrong version. Unless you have some experience with that, I'd advise against it.

[26atul05]

Ohh, I did not know that. Thank you! I'll install 3.2.0 version.

[capitalPSA]

To add on to this issue, NVidia Jetson AGX Xavier module runs Ubuntu 18.04 with OpenCV 3.3.1. This may mean not installing / uninstalling OpenCV 3.3.1 and installing OpenCV 3.2. I do not know if the installed OpenCV 3.3.1 is a stock install or has any optimizations turned on. I will try to install OpenCV 3.2 to see if the issue referenced by @26atul05 is solved.

[capitalPSA]

After a number of procedures, the NVidia Jetson Xavier module can run the image_pipeline package successfully. I do not think this is the correct area to post the necessary steps. Perhaps the NVidia Jetson forum is a more suitable area.

In short, OpenCV 3.3.1 was removed and OpenCV 3.2 was installed.

Thanks @roehling for the info.

[alezana]

This problem seems not to be fixed for Melodic on Ubuntu 18.04...

[roehling]

Apparently, the fix is merged to the master branch but not yet released in a new version.

[Light--]

The minimal example would be

#include <opencv2/highgui/highgui.hpp>

int main (int argc, char** argv)
{
    cv::startWindowThread();
    cv::waitKey(0);
    return 0;
}

Store as opencv_bug.cpp, compile with g++ opencv_bug.cpp -lopencv_highgui, and run the resulting a.out binary.

not helped but only turns out

Attempt to unlock mutex that was not locked
Aborted (core dumped)

i posted details in opencv/opencv#15504

[roehling]

I'm not exactly sure what you mean by "not helped", but the code you quoted is supposed to be the smallest possible example program that still exhibits the bug. It's not intended as a fix.

See e.g. here for a way to use this PR, or even better, get the ROS maintainer to release a new version to Melodic, so everyone can benefit.

[Light--]

I'm not exactly sure what you mean by "not helped", but the code you quoted is supposed to be the smallest possible example program that still exhibits the bug. It's not intended as a fix.

See e.g. here for a way to use this PR, or even better, get the ROS maintainer to release a new version to Melodic, so everyone can benefit.

sorry, but dou you mean the fix is to removing the "cv::startWindowThread();" from the minimal example? i just want to figure out what's the minimal fix for the minimal bug example...thanks

[aqiuxx]

Looking online, it seems like a GTK bug: https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=fbf38d16bcc26630f0f721d266509f5bc292f606
Which OpenCV and GTK are you using ? Can't you compile with Qt ? (I don't know if arch allows that).

Otherwise, go with rqt_image_view, it will not have that bug.

@vrabaud， thanks， its works for me when i change the command
rosrun rqt_image_view rqt_image_view image:=/camera/rgb/image_raw

[berktepebag]

Inspired by this Stackoverflow entry, I managed to fix the crash by removing the call to cv::startWindowThread().

A good workaround for the buggy GTK thread implementation is a ros::Timer that calls cv::waitKey() periodically.

I can prepare a PR if you want.

@roehling, your solution also worked with Jetson Nano and "image_transport Tutorials Subscribing To Images" example. Thanks

[Liuqibaa]

Inspired by this Stackoverflow entry, I managed to fix the crash by removing the call to cv::startWindowThread().

A good workaround for the buggy GTK thread implementation is a ros::Timer that calls cv::waitKey() periodically.

I can prepare a PR if you want.

Thank you, I have fixed my problem.