ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
2

Nodelets: pure virtual method called, process died (-6)

asked 2012-07-27 02:59:10 -0500

ipso gravatar image

updated 2012-07-27 03:48:35 -0500

I get the error in the question title everytime one of my Nodelet classes calls ros::requestShutdown(). I've tried debugging it in gdb, but besides the fact that the stacktrace is 5 pages (!) long, it doesn't tell me much, apart from a lot of references to boost::shared_ptr and checked_delete.

Is calling ros::requestShutdown() from a Nodelet unsupported or is this a bug somewhere?

Problem is the crash is causing my Nodelet destructors to not be called, which makes it hard to do proper cleanup of resources.

Breaking using ctrl+c does cleanly shutdown everything and calls destructors.


Edit: @Lorenz, you're right, I should've included more info.

System: Ubuntu Lucid (10.04.3), ROS Electric from debs.

The class that calls ros::requestShutdown() does so in a callback, whether that callback is called by a subscription or as a service doesn't matter.

On second thought it seems like the Bond dtor (frame 10) tries to stop/delete some timer (frame 9) which seems to try to use the ros::TimerManager (frame 7) which might have already been stopped/destructed.

Stacktrace:

pure virtual method called
terminate called without an active exception

Program received signal SIGABRT, Aborted.
0xb7fe2424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fe2424 in __kernel_vsyscall ()
#1  0xb785d651 in *__GI_raise (sig=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xb7860a82 in *__GI_abort () at abort.c:92
#3  0xb7aaa52f in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib/libstdc++.so.6
#4  0xb7aa8465 in ?? () from /usr/lib/libstdc++.so.6
#5  0xb7aa84a2 in std::terminate() () from /usr/lib/libstdc++.so.6
#6  0xb7aa9155 in __cxa_pure_virtual () from /usr/lib/libstdc++.so.6
#7  0xb7e883fa in ros::TimerManager<ros::WallTime, ros::WallDuration, ros::WallTimerEvent>::remove(int) ()
   from /opt/ros/electric/stacks/ros_comm/clients/cpp/roscpp/lib/libros.so
#8  0xb7ed9779 in ros::WallTimer::Impl::stop (this=0x8076730)
    at /tmp/buildd/ros-electric-ros-comm-1.6.7/debian/ros-electric-ros-comm/opt/ros/electric/stacks/ros_comm/clients/cpp/roscpp/src/libros/wall_timer.cpp:64
#9  0xb7ed9813 in ros::WallTimer::stop (this=0x806f690)
    at /tmp/buildd/ros-electric-ros-comm-1.6.7/debian/ros-electric-ros-comm/opt/ros/electric/stacks/ros_comm/clients/cpp/roscpp/src/libros/wall_timer.cpp:123
#10 0xb7f30cc3 in ~Bond (this=0x806f420, __in_chrg=<value optimised out>)
    at /tmp/buildd/ros-electric-bond-core-1.6.1/debian/ros-electric-bond-core/opt/ros/electric/stacks/bond_core/bondcpp/src/bond.cpp:91
#11 0x0804f019 in checked_delete<bond::Bond> (this=0x0)
    at /usr/include/boost/checked_delete.hpp:34
#12 boost::detail::sp_counted_impl_p<bond::Bond>::dispose (this=0x0)
    at /usr/include/boost/smart_ptr/detail/sp_counted_impl.hpp:78
#13 0xb7b17779 in boost::detail::sp_counted_base::release (this=0x80791d0, 
    __in_chrg=<value optimised out>)
    at /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:145
#14 ~shared_count (this=0x80791d0, __in_chrg=<value optimised out>)
    at /usr/include/boost/smart_ptr/detail/shared_count.hpp:217
#15 ~shared_ptr (this=0x80791d0, __in_chrg=<value optimised out>)
    at /usr/include/boost/smart_ptr/shared_ptr.hpp:169
#16 boost::shared_ptr<bond::Bond>::reset (this=0x80791d0, 
    __in_chrg=<value optimised out>)
    at /usr/include/boost/smart_ptr/shared_ptr.hpp:386
#17 ~Nodelet (this=0x80791d0, __in_chrg=<value optimised ...
(more)
edit retag flag offensive close merge delete

Comments

Without seeing the backtrace, it's hard to say what's going wrong. Although it might not tell you much, we might be able to infer something.

Lorenz gravatar image Lorenz  ( 2012-07-27 03:11:27 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2012-07-27 04:35:32 -0500

joq gravatar image

updated 2012-07-27 04:36:57 -0500

Nodelets are probably not supposed to call ros::requestShutdown(), but this is still a bug of some sort. Please open a defect ticket with a pointer back to this question.

edit flag offensive delete link more

Comments

1

Done. ticket/4431 seems to be related.

ipso gravatar image ipso  ( 2012-07-27 05:05:15 -0500 )edit

Yes. I knew about that ticket and the lack of a clean way for a nodelet to shut itself down. Trying ros::requestShutdown() was a reasonable idea, but I think it shuts down the entire nodelet manager process (and not cleanly).

joq gravatar image joq  ( 2012-07-27 08:29:49 -0500 )edit

@joq: well in my particular case I want to take the manager with me, but it should be done cleanly (or at least: not die in a horrible crash). Seeing the other tickets it'll probably be a while before this one is picked up.

ipso gravatar image ipso  ( 2012-07-27 08:40:40 -0500 )edit
1

Oh, I forgot: 'this one' got ticket/5506.

ipso gravatar image ipso  ( 2012-07-27 08:42:54 -0500 )edit

You use case can probably be fixed, although well-behaved nodelets should probably avoid doing that, because they don't know what other nodelets are running in that manager process.

joq gravatar image joq  ( 2012-07-27 08:49:20 -0500 )edit

Question Tools

Stats

Asked: 2012-07-27 02:59:10 -0500

Seen: 1,188 times

Last updated: Jul 27 '12