rrootage crashed with SIGSEGV in __libc_start_main()

Bug #261189 reported by Justin Dugger
Affects Status Importance Assigned to Milestone
rrootage (Debian)
Fix Released
rrootage (Ubuntu)
Fix Released

Bug Description

Binary package hint: rrootage

Segfaulted during play.

See also:

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
Signal: 11
SourcePackage: rrootage
 #0 0x0804ad55 in ?? ()
 #1 0x0804a16f in ?? ()
 #2 0xb7b62685 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
 #3 0x08049d81 in ?? ()
 ?? ()
 ?? ()
 __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

Revision history for this message
Justin Dugger (jldugger) wrote :
Revision history for this message
Apport retracing service (apport) wrote : Symbolic stack trace

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

Revision history for this message
Apport retracing service (apport) wrote : Symbolic threaded stack trace
Changed in rrootage:
importance: Undecided → Medium
Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

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.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

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

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

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...

Revision history for this message
Brian Murray (brian-murray) wrote :

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!

Changed in rrootage (Ubuntu):
status: New → Fix Released
Changed in rrootage (Debian):
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.