(1) I agree that more core exceptions like AIOOBE should give better
     diagnostics, at the (rare) expense of the StringBuilder work to
do it.

(2) If multiple people are seeing it on the same line number, then
it's
     likely a real problem.  Now to figure out how to reproduce it.

(3) Any threading going on here?  None of your stuff is synchronized.
     I doubt it, and your stuff all seems private, but worth asking.

(4) I can't find anything about dalvik's float implementations being
     asynchronous, like the sqrt() call putting some sort of "hold" on
     the registers being read.  That said, try using two frustum
copies
     instead of working in-situ.  It may be a workaround.  If you
can't
     reproduce the case yourself, those users may be willing to try a
     private build.

(5) Side note:  dividing is usually a lot slower than multiplying, so
     calculate 1/sqrt(b) then multiply each of the row by that number.
     Maybe the compiler is smart enough to see that, but don't leave
     it to chance.  Also, line 175 seems to calculate a value in vain.

On Jan 18, 8:49 am, RyanMcNally <therealr...@gmail.com> wrote:
> Hello all
>
> Hopefully someone out there can shed some light on this one, because
> it's got me completely stumped.
>
> I've received 5 reports, from 3 separate users on 2 different devices
> (ZTE blade and HTC Liberty), of an ArrayIndexOutOfBoundsException that
> I simply cannot explain.
>
> The stacktrace:
> java.lang.ArrayIndexOutOfBoundsException
> at com.ryanm.droid.rugl.util.geom.Frustum.extractFromOGL(Frustum.java:
> 180)
>

172:          frustum[ 3 ][ 0 ] = clip[ 3 ] - clip[ 1 ];
                frustum[ 3 ][ 1 ] = clip[ 7 ] - clip[ 5 ];
                frustum[ 3 ][ 2 ] = clip[ 11 ] - clip[ 9 ];
                frustum[ 3 ][ 3 ] = clip[ 15 ] - clip[ 13 ];
                /* Normalize the result */
                t =
                                sqrt( frustum[ 3 ][ 0 ] * frustum[ 3 ]
[ 0 ] + frustum[ 3 ][ 1 ]
                                                * frustum[ 3 ][ 1 ] +
frustum[ 3 ][ 2 ] * frustum[ 3 ][ 2 ] );
180:          frustum[ 3 ][ 0 ] /= t;
                frustum[ 3 ][ 1 ] /= t;
                frustum[ 3 ][ 2 ] /= t;
                frustum[ 3 ][ 3 ] /= t;

> Line 180 is:
>    frustum[ 3 ][ 0 ] /= t;
> However, the frustum array is declared as:
>    private final float[][] frustum = new float[ 6 ][ 4 ];
> so 3 and 0 are perfectly valid indices. The frustum array is not
> altered after declaration - it's private and there are only 4 "new"s
> in that file, none of which are redeclaring any of the frustum[]
> arrays. In addition, line 172 is:
>     frustum[ 3 ][ 0 ] = clip[ 3 ] - clip[ 1 ];
> and no error is raised.
>
> Possible causes that I've eliminated:
> 1) Different versions of the class, so line numbers don't match up - I
> wish it were that easy. The code was copied wholesale (url in the
> class javadoc), javafied and committed. I haven't touched it since so
> there are no other versions of this class.
> 2) Someone else has taken the code, b0rked it, and is distributing
> broken APKs - Seems unlikely, and the one user who responded to me
> claims he downloaded directly from my site.
> 3) The crash report is being mangled somewhere in the reporting
> process - I'm using this 
> class:http://code.google.com/p/rugl/source/browse/trunk/droid/DroidRUGL/src...
> to capture exceptions. If someone can explain how that can mangle
> reports sufficiently, I'd be grateful.
>
> Remaining possibilities:
> 1) Malicious users fabricating error reports - I'd have hoped that
> three people would have better things to do than to conspire to troll
> me with bizarre crash reports, but I suppose anything is possible :-/
> 2) VM bug
>
> It's always a sad state of affairs when it comes down to blaming the
> VM, especially for such innocuous code. I very much enjoy trusting the
> VM and knowing that any bugs are my own, but I just don't know what
> else to make of this.
> I'd be enormously grateful if someone could point out where I've gone
> wrong.
>
> On a side note, having AIOOBEs report the value of the incorrect index
> -as in the JVM- would have been very handy in this case.
>
> Regards
>
> Ryan McNally

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to