Closed eric-wieser closed 6 years ago
Removing that mutex in question, rqt still exits, but without std::terminate
being thrown - it sounds like it was shutting down anyway, but the shutdown doesn't happen in the right order, using a mutex after it is destructed.
Can you please provide more context: a reproducible example (it seems the same executable works for others just fine) or e.g. referencing on which exact line the mutex is failing.
For what it's worth, switching to VcXsrv from Xming made the problem go away.
I may try and reproduce the problem with Xming at some later date, and report back here
I have a problem. When I write rqt_image_view, rqt's windows opens but I can't see anything.
@turtlebot3sergi Please create a separate issue rather then commenting on an existing one. Especially include more information since your comment doesn't contain enough information to help you. In this specific case I would even ask you to post your question on answers.ros.org instead since it is unclear to me that it is cases by an actual problem in this package.
@eric-wieser I will close this for now. Please feel free to comment and this issue can be reopened if necessary.
This problem still appears to exist further in ROS Lunar, but is somehow sporadic. On WSL with Ubuntu 16.04 xenial and Kernel: x86_64 Linux 4.4.0-17134-Microsoft Using XMing on windows, and "export DISPLAY=:0" activated, problems occur with the following executables as examples: rqt, fails and gives the error:
failed to get the current screen resources
The X11 connection broke: I/O error (code 1)
XIO: fatal IO error 2 (No such file or directory) on X server ":0"
after 349 requests (349 known processed) with 0 events remaining.
rqt_image_view and rqt_console, work for me, but give the error / warning:
failed to get the current screen resources
QXcbConnection: XCB error: 170 (Unknown), sequence: 163, resource id: 90, major code: 146 (Unknown), minor code: 20
Can you please reopen. This is preventing some rqt development on WSL. Thanks
Have relisted problem under rqt, can stay closed here.
@GavinKane: Have you tried switching from Xming to VcXsrv? This might just be a bug in XMing, for which the free version is stuck at an old version of X11
Okay, I can confirm it does work with VCXsrv. Is possibly the problem you mention for XMing.
Thanks alot.
Having trouble, despite this working yesterday
Compare to
which is how
rqt_image_view
used to behave.I've attempted to debug, but all I've found is that
mutex_.m.__kind == -1
, and thatpthread_mutex_lock
is returningEINVAL
. This happened after building from source too.