Open furushchev opened 7 years ago
プロセスごと落ちてしまう原因はわかっていませんが、ros全体のログを眺めているとJSKのNodeletだけでなく一般的にそうなっている気がします。(→nodelet_core or bondの問題?)
その時のgdbのログは以下のようで、nodeletのunloadに失敗していると思われます。 Nodeletのloaderは自分でloadしたnodeletの辞書を持っていて、loadをrequestされた時に参照しているようです。 私見ではunloadの時に失敗して辞書からnodeletが削除されずにrespawnするとこうなるのではないかと思っています。 https://github.com/ros/nodelet_core/blob/6c561224958a575b604a067e149a55feb07044dc/nodelet/src/loader.cpp#L269
(gdb)
#0 0x00007ffff60bfc37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff60c3028 in __GI_abort () at abort.c:89
#2 0x00007ffff66c7535 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff66c56d6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff66c5703 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff66c5922 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007ffff7bb0601 in void boost::throw_exception<boost::lock_error>(boost::lock_error const&) () from /opt/ros/indigo/lib/libnodeletlib.so
#7 0x00007ffff7bb0705 in boost::unique_lock<boost::mutex>::lock() () from /opt/ros/indigo/lib/libnodeletlib.so
#8 0x00007fffd71e2205 in unique_lock (m_=..., this=0x7fffffffa0f0) at /usr/include/boost/thread/lock_types.hpp:124
#9 message_filters::Signal1<jsk_recognition_msgs::PolygonArray_<std::allocator<void> > >::removeCallback (this=0x1486608, helper=...)
at /opt/ros/indigo/include/message_filters/signal1.h:102
#10 0x00007fffd72634ca in disconnectAll (this=0x148cc00) at /opt/ros/indigo/include/message_filters/synchronizer.h:351
#11 message_filters::Synchronizer<message_filters::sync_policies::ExactTime<jsk_recognition_msgs::PolygonArray_<std::allocator<void> >, jsk_recognition_msgs::ModelCoefficientsAr
ray_<std::allocator<void> >, message_filters::NullType, message_filters::NullType, message_filters::NullType, message_filters::NullType, message_filters::NullType, message_filte
rs::NullType, message_filters::NullType> >::~Synchronizer (this=0x148cc00, __in_chrg=<optimized out>) at /opt/ros/indigo/include/message_filters/synchronizer.h:228
#12 0x00007fffd7263689 in destroy (this=0x148cbf8) at /usr/include/boost/smart_ptr/make_shared_object.hpp:57
#13 operator() (this=0x148cbf8) at /usr/include/boost/smart_ptr/make_shared_object.hpp:87
#14 boost::detail::sp_counted_impl_pd<message_filters::Synchronizer<message_filters::sync_policies::ExactTime<jsk_recognition_msgs::PolygonArray_<std::allocator<void> >, jsk_rec
ognition_msgs::ModelCoefficientsArray_<std::allocator<void> >, message_filters::NullType, message_filters::NullType, message_filters::NullType, message_filters::NullType, messag
e_filters::NullType, message_filters::NullType, message_filters::NullType> >*, boost::detail::sp_ms_deleter<message_filters::Synchronizer<message_filters::sync_policies::ExactTi
me<jsk_recognition_msgs::PolygonArray_<std::allocator<void> >, jsk_recognition_msgs::ModelCoefficientsArray_<std::allocator<void> >, message_filters::NullType, message_filters::
NullType, message_filters::NullType, message_filters::NullType, message_filters::NullType, message_filters::NullType, message_filters::NullType> > > >::dispose (this=0x148cbe0)
at /usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp:153
#15 0x000000000040624e in boost::detail::sp_counted_base::release() ()
#16 0x00007fffd725aaf8 in ~shared_count (this=0x14865f8, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/detail/shared_count.hpp:371
#17 ~shared_ptr (this=0x14865f0, __in_chrg=<optimized out>) at /usr/include/boost/smart_ptr/shared_ptr.hpp:328
#18 ~PolygonArrayLikelihoodFilter (this=0x1486470, __in_chrg=<optimized out>)
at /home/m-takeda/catkin_ws/src/jsk-ros-pkg/jsk_recognition/jsk_pcl_ros_utils/include/jsk_pcl_ros_utils/polygon_array_likelihood_filter.h:53
#19 jsk_pcl_ros_utils::PolygonArrayLikelihoodFilter::~PolygonArrayLikelihoodFilter (this=0x1486470, __in_chrg=<optimized out>)
at /home/m-takeda/catkin_ws/src/jsk-ros-pkg/jsk_recognition/jsk_pcl_ros_utils/include/jsk_pcl_ros_utils/polygon_array_likelihood_filter.h:53
#20 0x00007ffff7bb0831 in void class_loader::ClassLoader::onPluginDeletion<nodelet::Nodelet>(nodelet::Nodelet*) () from /opt/ros/indigo/lib/libnodeletlib.so
#21 0x000000000040624e in boost::detail::sp_counted_base::release() ()
#22 0x00007ffff7baac09 in nodelet::Loader::unload(std::string const&) () from /opt/ros/indigo/lib/libnodeletlib.so
#23 0x00007ffff7bb3efb in nodelet::LoaderROS::unload(std::string const&) () from /opt/ros/indigo/lib/libnodeletlib.so
#24 0x00007ffff77644ed in bond::Bond::flushPendingCallbacks() () from /opt/ros/indigo/lib/libbondcpp.so
#25 0x00007ffff776467b in bond::Bond::onHeartbeatTimeout() () from /opt/ros/indigo/lib/libbondcpp.so
#26 0x00007ffff748a0a0 in ros::TimerManager<ros::WallTime, ros::WallDuration, ros::WallTimerEvent>::TimerQueueCallback::call() () from /opt/ros/indigo/lib/libroscpp.so
#27 0x00007ffff74b3107 in ros::CallbackQueue::callOneCB(ros::CallbackQueue::TLS*) () from /opt/ros/indigo/lib/libroscpp.so
#28 0x00007ffff74b3c53 in ros::CallbackQueue::callAvailable(ros::WallDuration) () from /opt/ros/indigo/lib/libroscpp.so
#29 0x00007ffff74fc175 in ros::SingleThreadedSpinner::spin(ros::CallbackQueue*) () from /opt/ros/indigo/lib/libroscpp.so
#30 0x00007ffff74e3d9b in ros::spin() () from /opt/ros/indigo/lib/libroscpp.so
#31 0x000000000040494e in main ()
@k-okada @YoheiKakiuchi @mmurooka さん DRCの時に認識でnodeletをよく使っていたと思いますが、この問題は起きていましたでしょうか?(なんとなく起きていた記憶がある気がする)
cc @wkentaro
起動時ではなく起動は終わって実行している途中に突然落ちることがあるということでしょうか. DRCのときにもその問題はあって, どうしても解決できないのでstandalone_complexed_nodeletというのを@garaemonさんが作ってそれを使っていました. https://github.com/jsk-ros-pkg/jsk_demos/blob/master/jsk_2015_06_hrp_drc/drc_task_common/launch/fc/valve_recognition.launch がDRCのバルブ認識のlaunchでstandalone_complexed_nodeletを使っています. http://jsk-docs.readthedocs.io/en/latest/jsk_common/doc/jsk_topic_tools/lib/standalone_complexed_nodelet.html にちょっと長いですが普通のnodeletで落ちる理由が書いてあります.
DRCではこのようにして対応していましたが,その後あまり引き継がれていませんし, ベストは普通のnodeletを落ちないようにすることだとは思います.
DRCではこのようにして対応していましたが,その後あまり引き継がれていませんし, ベストは普通のnodeletを落ちないようにすることだとは思います.
メンテはできていませんが、multisense関連の点群等でnodeletを使っているものはほぼstandaloneになっていますね。 https://github.com/jsk-ros-pkg/jsk_common/blob/master/jsk_tilt_laser/launch/multisense_laser_pipeline.launch https://github.com/jsk-ros-pkg/jsk_robot/blob/master/jsk_robot_common/jsk_robot_startup/launch/multisense_local.launch
問題は2つあるような気がするが、これは分けられない問題だったのだろうか?
2.が解決すればunload/loadでたまにトピックが途切れるがなんとなく動き続けるようにならないのかな。 あと、@garaemon の文書にあるhartbeatが途切れたと判断する時間を十分に大きくするようにはできないのだろうか。
@mmurooka @YoheiKakiuchi コメントありがとうございます。 @mmurooka さんに貼っていただいたリンクに書いてあったことを踏まえると、ご指摘の通り問題は2つになりそうです。
hartbeatが途切れたと判断する時間を十分に大きくするようにはできないのだろうか
ソースコードを見ると、nodeletパッケージを再コンパイルすれば可能のようです。 それで一度様子を見てみます。 (デフォルトはタイムアウトが1秒)
unload/load 時に落ちる
こちらはプログラムの何処かで、エラー(リークとか?)が起きて、unloadができなくなったのか、unload処理自体に問題があるのかをまず切り分けてわかりそうな範囲でデバックしていこうと思います。
こちらはプログラムの何処かで、エラー(リークとか?)が起きて、unloadができなくなったのか、unload処理自体に問題があるのかをまず切り分けて
@furushchev 切り分けてテストコードを作りましょう.
Nodeletを動かしているとなんらかの理由で時折プロセスごと落ちてしまいます。 この時
respawn="true"
にしていると一定の確率で、respawnにも失敗してしまうようです。