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
(text/plain)