On Sat, Jan 29, 2011 at 2:06 PM, Tully Foote <tfoote@willowgarage.com> wrote:
> Hi Agusto,
>
> Based on your backtrace it looks like you have a bug in the parseLaserData
> method.
> """/home/usad1/workspace/usad/cart/cart/lib/libusad_nodelet.so(_ZN12usad_nodelet22nodelet_LaserPublisher14parseLaserDataERKSs+0xdbc)[0x46e1ec]"""
>
> Nodelets are dynamically loaded into the manager and if a nodelet crashes it
> will take down the manager.  A way to isolate any individual nodelet to make
> debugging easier is to run it in standalone mode.  You loose the
> intraprocess communication, but decrease the number of threads to debug.

Nodelets are harder to debug than nodes. To run valgrind on the
camera1394 driver nodelet (for example), I do something like this:

 $ roscd nodelet
 $ valgrind bin/nodelet standalone camera1394/driver

You may want some additional valgrind options, such as
--leak-check=full --track-origins=yes.

Running the nodelet standalone with gdb is somewhat similar:

 $ gdb bin/nodelet
 gdb> run standalone camera1394/driver

-- 
 joq