Justin: Geez that was fast! I only posted that LKML mail report yesterday...
The segfault isn't actually in __libc_start_main though - it's within moveFoes() in rrootage itself. Here's a backtrace on a build of rrootage with debug symbols within it: Thread 1 (Thread 0xb782c6c0 (LWP 9299)): #0 moveFoes () at foe.cc:247 #1 0x0804a18f in main (argc=1, argv=0xbfd66354) at rr.c:112 As mentioned in the LKML post, rrootage access an array beyond its bounds. degutil.c sets sctbl to a size of 1280 ( http://www.koders.com/c/fid67AB4F26D7BA9DCD7BE5B2BDFFD02347E201D963.aspx#L16 , SC_TABLE_SIZE is 1024 as defined in degutil.h). After adding a number of asserts I found that FoeCommand::doChangeDirection in foecommand.cc ( http://www.koders.com/cpp/fid33E7735546356BB4A2D4B57AB1FA2D75B07F9A44.aspx#L78 ) will set foe->d to values larger than 1023 (it's an open question as to whether the degrees passed in d should ever be greater than 360 but I've seen values over 400). The problem is that moveFoes foe->d (and worse on the following line foe->d + 256) to index into sctbl they go past the end of the array. Presumably newer kernels have changed how things are being laid out and correctly flag the out of bounds error. Please find a patch that caps the value at 1023 attached (other parts of foecommand.cc do something similar already). This resolves the problem that I was seeing. It's also a pity that the debug package for rrootage does not contain any meaningful debug information. ** Attachment added: "2.6.25-segfault.patch" http://launchpadlibrarian.net/17063343/2.6.25-segfault.patch -- rrootage crashed with SIGSEGV in __libc_start_main() https://bugs.launchpad.net/bugs/261189 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
