add boost::mutex::scoped_lock before accessing rt_active_goal_

[k-okada]

No description provided.

[bmagyar]

I'm still getting a crash, although this seems to be different than before (that being a simple segmentation fault).

Usually after a couple of seconds of running the script from #301 with the ur_gazebo setup.

gzserver: /usr/include/boost/smart_ptr/shared_ptr.hpp:648: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = realtime_tools::RealtimeServerGoalHandle<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >; typename boost::detail::sp_member_access<T>::type = realtime_tools::RealtimeServerGoalHandle<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >*]: Assertion `px != 0' failed.
Aborted (core dumped)
[gazebo-2] process has died [pid 4104, exit code 134, cmd /opt/ros/kinetic/lib/gazebo_ros/gzserver -e ode worlds/empty.world __name:=gazebo __log:=/home/bence/.ros/log/04a85136-33ef-11e8-999d-e8b1fc66403b/gazebo-2.log].
log file: /home/bence/.ros/log/04a85136-33ef-11e8-999d-e8b1fc66403b/gazebo-2*.log

What's your experience with the same test? More debug info from me soon!

[k-okada]

sorry, yes I pushed without detailed experience, please check updated version.

…

-- ◉ Kei Okada 2018-03-30 16:54 GMT+09:00 Bence Magyar <[email protected]>:

I'm still getting a crash, although this seems to be different than before (that being a simple segmentation fault). Usually after a couple of seconds of running the script from #301 <#301> with the ur_gazebo setup. gzserver: /usr/include/boost/smart_ptr/shared_ptr.hpp:648: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = realtime_tools::RealtimeServerGoalHandle<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >; typename boost::detail::sp_member_access<T>::type = realtime_tools::RealtimeServerGoalHandle<control_msgs::FollowJointTrajectoryAction_<std::allocator<void> > >*]: Assertion `px != 0' failed. Aborted (core dumped) [gazebo-2] process has died [pid 4104, exit code 134, cmd /opt/ros/kinetic/lib/gazebo_ros/gzserver -e ode worlds/empty.world __name:=gazebo __log:=/home/bence/.ros/log/04a85136-33ef-11e8-999d-e8b1fc66403b/gazebo-2.log]. log file: /home/bence/.ros/log/04a85136-33ef-11e8-999d-e8b1fc66403b/gazebo-2*.log What's your experience with the same test? More debug info from me soon! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#325 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAeG3HE9LJGW9sS3AO6T5tQ4gYqfAaUWks5tjeS8gaJpZM4TBVyO> .

[bmagyar]

Now it hangs Gazebo entirely: time gets stuck when I send the new goal.
I'm experiencing the same both in release and debug modes. The first message hangs time already.

[k-okada]

that's strange , I had similar situation when I lock entire goalCB function, but 8925e70 works ok for me with #301 (comment) example

can you remove
8925e70#diff-9ec3f32075624b226ce54cd89fd6a606R631
line and try again.

[bmagyar]

It probably had to do with a build cache...I've tried in a new workspace and I'm experiencing no crashes now.

[mathias-luedtke]

Is this patch RT-safe?

[bmagyar]

Good to bring that up again.
I'd think it is, but I think it's sensible to further look into the implications of using boost::scoped_lock vs the common m.try_lock() pattern we have in controllers.

For ref, I found some scoped_lock reference in realtime_tools::RealtimeBuffer and realtime_tools::RealtimeBox too. RealtimeBuffer has an interesting mix of usage of scoped_lock and m.try_lock().

[mathias-luedtke]

The non-RT can lock unconditionally (it might block), the RT part should not block.
In addition locks might lead to syscalls.

RealtimeBuffer has an interesting mix of usage of scoped_lock and m.try_lock().

try-locks and scope-lock can be even mixed:
boost::mutex::scoped_lock lock(mutex, boost::try_to_lock);

[mathias-luedtke]

I don't think that we should add this update-wide lock.
#301 can be fixed without.
rt_active_goal_ should never get accessed directly, but from a local copy of the shared pointer.

[7675t]

Hi, do you mean we should just do as #327 ? @ipa-mdl
At a glance of the code, it uses boost::shared_ptr as a kind of lock-free access between threads, then we should always use a copy of the pointer in update().

[mathias-luedtke]

Hi, do you mean we should just do as #327 ? @ipa-mdl

@7675t: Thanks, this is what I meant 👍

[bmagyar]

Closing in favour of #327