workaround for #15, registrer exit command

[k-okada]

not sure if this is the correct fix, just a one proposal for workaround except adding moveit_commander.os._exit(0) for all of our program.
But i think we should try to find the root of the bug, may be some confront on binding roscpp on python ...

[v4hn]

@k-okada I failed to reproduce the bug over here with indigo-devel. Do you still experience the bug?
If yes, could you provide a working test case that demonstrates it?

[k-okada]

Yes, try

term1$ rtmlaunch nextage_moveit_config nextage_demo.launch # (note that we need to use rtmlaunch, not roslaunch)
term2$  curl https://raw.githubusercontent.com/RyuYamamoto/rtmros_nextage/moveit_demonstration/nextage_ros_bridge/script/nextage_moveit_sample.py | python -

and the python code will end with

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >'
  what():  boost: mutex lock failed in pthread_mutex_lock: Invalid argument
Aborted (core dumped)

I think this could happens to any kind of moveit robots, if you have moveit launch file which you're familiar with, please let me know.

[v4hn]

On Thu, Jul 28, 2016 at 05:06:50PM -0700, Kei Okada wrote:

curl https://raw.githubusercontent.com/RyuYamamoto/rtmros_nextage/moveit_demonstration/nextage_ros_bridge/script/nextage_moveit_sample.py | python -

I just tested this script with MoveIt's indigo-devel branches and roslaunch pr2_moveit_config demo.launch (I have never heard about rtmlaunch before).
The script manages to move the arm twice and some of the move requests fail with "No motion plan found".
In the end the script terminates perfectly fine though.
Could you test this on your setup?

[rhaschke]

I think this relates to moveit/moveit_ros#592 which was tackled by moveit/moveit_ros#705 and moveit/moveit_ros#706. However, the issue is still present in moveit_commander. I added a test called cleanup.test in moveit/moveit_ros#729, which fails in indigo-devel.
In jade-devel it automagically succeeds... I didn't have time yet to look into this in more detail.

[k-okada]

@v4hn the problem is not "no motion plan found", but the python exists with

python: /usr/include/boost/thread/pthread/pthread_mutex_scoped_lock.hpp:26: boost::pthread::pthread_mutex_scoped_lock::pthread_mutex_scoped_lock(pthread_mutex_t*): Assertion `!pthread_mutex_lock(m)' failed.
Aborted (core dumped)

And that sometimes scared users.

and this is fixed by start-jsk/denso#80

[v4hn]

I am aware of that.

Ok, as it will take more time to fix this properly and might even involve a gcc bug (@rhaschke is that right?),
I suppose it's fine to have this workaround upstream.

Could you please add the line

# TODO: repair broken destruction of MoveIt objects in python to remove this workaround

to your patch? This will make it pop up when looking for TODOs.

Also, this repository is deprecated and we moved the package into https://github.com/ros-planning/moveit . Could you file a request with this patch there, so we can merge it?

[k-okada]

Ok, created new pull request at moveit/moveit#105

[rhaschke]

-1
This issue is in ros_comm: ros/ros_comm#871.
Doing os._exit(0) avoids any cleanup and always returns with success code 0. I think in case of true exceptions, that's not what we want. According to my investigation, it might be useful to trigger ros.shutdown() on exit.