rrootage crashed with SIGSEGV in __libc_start_main()

[Justin Dugger]

Binary package hint: rrootage

Segfaulted during play.

See also:
http://lkml.org/lkml/2008/8/24/151

ProblemType: Crash
Architecture: i386
CrashCounter: 1
DistroRelease: Ubuntu 8.10
ExecutablePath: /usr/games/rrootage
NonfreeKernelModules: nvidia
Package: rrootage 0.23a-7
ProcAttrCurrent: unconfined
ProcCmdline: rrootage
ProcEnviron:
 SHELL=/bin/bash
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/username/bin
 LANG=en_US.UTF-8
Signal: 11
SourcePackage: rrootage
Stacktrace:
 #0 0x0804ad55 in ?? ()
 #1 0x0804a16f in ?? ()
 #2 0xb7b62685 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
 #3 0x08049d81 in ?? ()
StacktraceTop:
 ?? ()
 ?? ()
 __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
 ?? ()
Title: rrootage crashed with SIGSEGV in __libc_start_main()
Uname: Linux 2.6.26-5-generic i686
UserGroups: adm admin audio cdrom dialout dip floppy fuse lpadmin netdev plugdev powerdev root scanner video

[Apport retracing service (apport)]

StacktraceTop:main (argc=1, argv=0xbfe36464) at rr.c:121

[Sitsofe Wheeler (sitsofe)]

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.

[Sitsofe Wheeler (sitsofe)]

I should also mention that this bug is present in the Hardy version of rrootage - it just might trigger very rarely.

[Sitsofe Wheeler (sitsofe)]

Well the good news is that someone reported the issue to the debian maintainer and the issue was fixed upstream - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504229 . The sad part is that my effort here was a complete waste of time...

[Brian Murray (brian-murray)]

This was fixed upstream in Debian in version 0.23a-8 of the package which is now included in Jaunty Jackalope. I'm sorry that we didn't get your patch incorporated sooner, we are actively working on improving the patch workflow and decreasing the quantity of open bugs with patches. Its how I found this one!