(1) Yeah, it would have been *fascinating* to see the value of the offending index
(2) Glad someone agrees - self-doubt is my default mode in cases like this ;-) (3) Threading is usually the culprit for weird errors like this. Unfortunately, there's no threading happening here. Also, as the frustum arrays are only ever defined once I can't see how threading could cause a AIOOBE. The method being called simultaneously from 2 threads could cause incorrect results, but not an AIOOBE. (4) Perhaps... Feels like shooting in the dark though. The current code is, AFAICS, statically provable not to throw an AIOOBE according to the language spec, yet here we are. I'm not sure how to write a workaround without relying on the language spec :-/ (5) Good catch, cheers! This code is only called at most once per frame, but still, every little helps... On Jan 18, 6:48 pm, Hari Edo <hari....@gmail.com> wrote: > (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
