Code works in Electric flawlessly but segfaults in Fuerte
Dear ROS brothers,
I found this implementation of TinySLAM for ROS called coreslam, which I checked out from the University of Albany repository.
As far as I understood, the code was developed back in 2008 and the latest change was made in December 2010. So I guess the pkg was working fine with CTurtle and most likely Diamondback.
I have a Fuerte installation in Ubuntu 11.10 and I was able to compile the pkg after explicitly linking the signals boost library (as suggested in the Fuerte Migration Guide) in the CMakeList.txt:
rosbuild_add_boost_directories()
rosbuild_add_executable(bin/slam_coreslam src/slam_coreslam.cpp src/main.cpp)
rosbuild_link_boost(bin/slam_coreslam signals)
As soon as I run the slam_coreslam node, I receive an immediate and deathly segmentation fault. I understand that the program crashes in line 27 of main.cpp, when the SlamCoreSlam class is initialized (slam_coreslam.h, slam_coreslam.cpp), because when I comment out this line, it will not segfault.
I have used gdb to debug the problem, here is the gdb stack backtrace:
(gdb) exec-file slam_coreslam
(gdb) r
Starting program: /home/david/stacks/coreslam/bin/slam_coreslam slam_coreslam
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x08062ac8 in ?? ()
(gdb) bt
#0 0x08062ac8 in ?? ()
#1 0x004ba113 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#2 0x08062be9 in ?? ()
Backtrace stopped: Not enough registers or memory available to unwind further
(gdb)
I've also run it with valgrind, here is the output:
david@David-Laptop:~/stacks/coreslam/bin$ valgrind ./slam_coreslam
==7329== Memcheck, a memory error detector
==7329== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==7329== Using Valgrind-3.6.1-Debian and LibVEX; rerun with -h for copyright info
==7329== Command: ./slam_coreslam
==7329==
==7329== Warning: client switching stacks? SP change: 0xbe824fb0 --> 0xbdffbc90
==7329== to suppress, use: --max-stackframe=8557344 or greater
==7329== Invalid write of size 4
==7329== at 0x8062AB7: main (main.cpp:25)
==7329== Address 0xbe824fac is on thread 1's stack
==7329==
==7329== Invalid write of size 4
==7329== at 0x8062AC8: main (main.cpp:26)
==7329== Address 0xbdffbc98 is on thread 1's stack
==7329==
==7329==
==7329== Process terminating with default action of signal 11 (SIGSEGV)
==7329== Access not within mapped region at address 0xBDFFBC98
==7329== at 0x8062AC8: main (main.cpp:26)
==7329== If you believe this happened as a result of a stack
==7329== overflow in your program's main thread (unlikely but
==7329== possible), you can try to increase the size of the
==7329== main thread stack using the --main-stacksize= flag.
==7329== The main thread stack size used in this run was 8388608.
==7329==
==7329== Process terminating with default action of signal 11 (SIGSEGV)
==7329== Access not within mapped region at address 0xBDFFBC8C
==7329== at 0x402242C: _vgnU_freeres (vg_preloaded.c:58)
==7329== If you believe this happened as a result of a stack
==7329== overflow in your program's main thread (unlikely but
==7329== possible), you can try to increase the size of the
==7329== main thread stack using the --main-stacksize= flag.
==7329== The main thread stack size used in ...
To get help, you will probably need to update your question to include the gdb stack backtrace and any other relevant information.
Thank you joq. Just edited the post :) Any ideas, anyone?