Code works in Electric flawlessly but segfaults in Fuerte

Question

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 this run was 8388608.
==7329== 
==7329== HEAP SUMMARY:
==7329==     in use at exit: 29,809 bytes in 429 blocks
==7329==   total heap usage: 1,296 allocs, 867 frees, 53,217 bytes allocated
==7329== 
==7329== LEAK SUMMARY:
==7329==    definitely lost: 0 bytes in 0 blocks
==7329==    indirectly lost: 0 bytes in 0 blocks
==7329==      possibly lost: 4,632 bytes in 159 blocks
==7329==    still reachable: 25,177 bytes in 270 blocks
==7329==         suppressed: 0 bytes in 0 blocks
==7329== Rerun with --leak-check=full to see details of leaked memory
==7329== 
==7329== For counts of detected and suppressed errors, rerun with: -v
==7329== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 67 from 8)
Segmentation fault

I guess it is a library problem...

I have also tried to compile the pkg (Original CMakeLists.txt) with an Electric instalation that I have in a different computer and found out that the node runs smoothly with no problem at all (working similarly to Gmapping)!

I was completely surprised and I am really curious about what may be causing the segmentation fault in Fuerte. The only thing that I made differently was including the signal boost libraries in the CMakeLists.txt before compiling.

Is anyone willing to help this curious young man on finding a working solution of this pkg for Fuerte?

Thanks in advance!

---

Originally posted by DavidPortugal on ROS Answers with karma: 349 on 2012-12-29

Post score: 1

---

Original comments

Comment by joq on 2013-01-03:
To get help, you will probably need to update your question to include the gdb stack backtrace and any other relevant information.

Comment by DavidPortugal on 2013-01-07:
Thank you joq. Just edited the post :) Any ideas, anyone?

Answer 1

So the backtrace ("Not enough registers or memory available to unwind further") made me wondering about memory issues. So instead of instantiating the class SlamCoreSlam, I simply tried to allocate memory in main.cpp.

So originally we had:

int main(int argc, char** argv)
{
    ros::init(argc, argv, "slam_coreslam");
    SlamCoreSlam cs;
    ros::spin();
    return(0);
}

Which, I changed to:

int main(int argc, char** argv)
{
    ros::init(argc, argv, "slam_coreslam");
    //SlamCoreSlam cs;
    SlamCoreSlam *cs = new SlamCoreSlam[1];
    ros::spin();
    delete[] cs;
    return(0);
}

And now it works fine. I don't know what is going on in the code to cause the segfault and still don't really understand why the first one would work in electric, but not in fuerte. But, at least, the problem was solved. Hope the solution may help some one in the future.

---

Originally posted by DavidPortugal with karma: 349 on 2013-01-08

This answer was ACCEPTED on the original site

Post score: 3