New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

image_view: Attempt to unlock mutex that was not locked #201

Closed
abhinavkssk opened this Issue Jun 10, 2016 · 17 comments

Comments

Projects
None yet
5 participants
@abhinavkssk

abhinavkssk commented Jun 10, 2016

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

This comment has been minimized.

Contributor

vrabaud commented Jun 12, 2016

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

This comment has been minimized.

abhinavkssk commented Jun 12, 2016

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

This comment has been minimized.

Contributor

vrabaud commented Jul 24, 2016

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

@abhinavkssk

This comment has been minimized.

abhinavkssk commented Jul 24, 2016

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

This comment has been minimized.

Contributor

vrabaud commented Jul 24, 2016

@vrabaud

This comment has been minimized.

Contributor

vrabaud commented Jul 24, 2016

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

@abhinavkssk

This comment has been minimized.

abhinavkssk commented Jul 24, 2016

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

This comment has been minimized.

Contributor

vrabaud commented Jul 24, 2016

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

This comment has been minimized.

abhinavkssk commented Jul 24, 2016

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

This comment has been minimized.

Contributor

vrabaud commented Jul 24, 2016

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

This comment has been minimized.

Contributor

vrabaud commented Jul 24, 2016

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.

@vrabaud vrabaud closed this Jul 24, 2016

@roehling

This comment has been minimized.

roehling commented Jun 25, 2018

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

@roehling

This comment has been minimized.

roehling commented Jun 26, 2018

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

This comment has been minimized.

kunaltyagi commented Jun 27, 2018

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

This comment has been minimized.

roehling commented Jun 27, 2018

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

This comment has been minimized.

kunaltyagi commented Jun 27, 2018

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

@AmeyHande

This comment has been minimized.

AmeyHande commented Nov 7, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment