Reproducible rRootage segfault with 2.6.25 and above (regression?)

[Sitsofe Wheeler <sitsofe@yahoo.com>]

I've found that when running certain levels in the game rRootage on 
kernels later than 2.6.24 a segfault will be caused. This segfault is 
not there on 2.6.24 (and below) though...

Frustratingly I have been unable to bisect my way to the kernel change 
because I hit a USB timeout issue bisecting between 2.6.24-2.6.25 which 
made booting impossible. Further it seems there are a number of 
conditions that need to be met before the problem manifests itself:

1. Compiler optimisation used to compile rRootage must be -O1 or higher 
(-Os also triggers the problem)
2. The running kernel (going by release) must be 2.6.25 or later.
3. The gcc used to compile the game must (seemingly) not be 3.3 (using 
4.2 shows the problem. Other versions may also show up the problem).
4. Not every level in every mode will show the problem (it seems linked 
to certain patterns). I have found level 9A in the green "GigaWing" mode 
is usually quick to trigger the issue but you may have to kill the first 
enemy once to see the problem (if you can just get to even that part it 
is likely the problem is non present).

I have seen the issue on a range of 2.6.25+ kernels (both hand compiled 
on openSUSE kernels and a pre-shipped 2.6.26-5 from Ubuntu 8.10).

The segfault in question is due to an array being accessed beyond its 
bounds (the array sctbl on this line 
http://www.koders.com/cpp/fid93F842B399CA68D754CADEC374AE934EED72C07D.aspx#L246 
). Running the game under valgrind on a 2.6.24 kernel did not generate 
any  warnings about that array (using MALLOC_CHECK_=2 didn't generate 
any warnings either). The problem has been reproduced on two different 
machines (a Thinkpad T60 and an eeePC).

Finally, this also afflicts a prebuilt binary from 2004 (which probably 
wasn't built using gcc4.x 
http://sourceforge.net/project/showfiles.php?group_id=112441 ).

The issue is fiddly but reproducible. All help in pinpointing the 
problem source is appreciated.

-- 
Sitsofe | http://sucs.org/~sits/