[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
The values aren't identical. e.g.: // right frustum[ 0 ][ 0 ] = clip[ 3 ] - clip[ 0 ]; versus // left frustum[ 1 ][ 0 ] = clip[ 3 ] + clip[ 0 ]; Took me while to spot that myself though, this kind of stuff is well over my head :-) Ryan On Jan 19, 10:07 pm, DanH danhi...@ieee.org wrote: I'm kind of curious as to why you don't just copy the left, top, and near planes from the right, bottom, and far planes, vs recalculating the identical results. On Jan 18, 7: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) at com.ryanm.droid.rugl.util.FPSCamera.setPosition(FPSCamera.java:174) at com.ryanm.minedroid.BlockView.draw(BlockView.java:318) at com.ryanm.droid.rugl.Game.onDrawFrame(Game.java:247) at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java: 1332) at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1116) ... You can view the offending file here:http://code.google.com/p/rugl/source/browse/trunk/droid/DroidRUGL/src... 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 news 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
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
No native code I'm afraid. I've given the three users apk's with the improved exception logging, and so begins the waiting game... Ryan On Jan 20, 1:12 am, fadden fad...@android.com wrote: That is definitely strange. I can't see any reason why that exception would be thrown from that point. If you suspect that the object has been damaged, there's an excellent chance that your improved exception handler will throw an exception. Or crash. Either way you will have learned something new. :-) Future versions of the VM do show additional detail on array index problems. Is there any native code involved? JNI code can generate array bounds exceptions, and if somebody crossed up JNIEnv* it could end up on the wrong thread. Of course, it's *highly* unlikely that multiple occurrences on different devices would have the same stack trace if the failure is actually happening elsewhere. There are no exceptions involved in floating-point division by zero on Android (other than whatever the VFP hardware does internally). -- 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
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
You didn't put an exception handler around the subscript operation in the exception handler. On Jan 20, 6:38 am, RyanMcNally therealr...@gmail.com wrote: No native code I'm afraid. I've given the three users apk's with the improved exception logging, and so begins the waiting game... Ryan On Jan 20, 1:12 am, fadden fad...@android.com wrote: That is definitely strange. I can't see any reason why that exception would be thrown from that point. If you suspect that the object has been damaged, there's an excellent chance that your improved exception handler will throw an exception. Or crash. Either way you will have learned something new. :-) Future versions of the VM do show additional detail on array index problems. Is there any native code involved? JNI code can generate array bounds exceptions, and if somebody crossed up JNIEnv* it could end up on the wrong thread. Of course, it's *highly* unlikely that multiple occurrences on different devices would have the same stack trace if the failure is actually happening elsewhere. There are no exceptions involved in floating-point division by zero on Android (other than whatever the VFP hardware does internally). -- 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
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
BTW, I'm betting that the problem never reappears for those three users. On Jan 20, 6:38 am, RyanMcNally therealr...@gmail.com wrote: No native code I'm afraid. I've given the three users apk's with the improved exception logging, and so begins the waiting game... Ryan On Jan 20, 1:12 am, fadden fad...@android.com wrote: That is definitely strange. I can't see any reason why that exception would be thrown from that point. If you suspect that the object has been damaged, there's an excellent chance that your improved exception handler will throw an exception. Or crash. Either way you will have learned something new. :-) Future versions of the VM do show additional detail on array index problems. Is there any native code involved? JNI code can generate array bounds exceptions, and if somebody crossed up JNIEnv* it could end up on the wrong thread. Of course, it's *highly* unlikely that multiple occurrences on different devices would have the same stack trace if the failure is actually happening elsewhere. There are no exceptions involved in floating-point division by zero on Android (other than whatever the VFP hardware does internally). -- 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
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
There's been no indication that the arrays could be null so far, but I guess at this point we are fully through the looking-glass so all bets are off. Welcome to bizarro-world, engage null-checks for your safety, convenience and psychological integrity. Ryan On Jan 20, 1:07 pm, DanH danhi...@ieee.org wrote: You didn't put an exception handler around the subscript operation in the exception handler. On Jan 20, 6:38 am, RyanMcNally therealr...@gmail.com wrote: No native code I'm afraid. I've given the three users apk's with the improved exception logging, and so begins the waiting game... Ryan On Jan 20, 1:12 am, fadden fad...@android.com wrote: That is definitely strange. I can't see any reason why that exception would be thrown from that point. If you suspect that the object has been damaged, there's an excellent chance that your improved exception handler will throw an exception. Or crash. Either way you will have learned something new. :-) Future versions of the VM do show additional detail on array index problems. Is there any native code involved? JNI code can generate array bounds exceptions, and if somebody crossed up JNIEnv* it could end up on the wrong thread. Of course, it's *highly* unlikely that multiple occurrences on different devices would have the same stack trace if the failure is actually happening elsewhere. There are no exceptions involved in floating-point division by zero on Android (other than whatever the VFP hardware does internally). -- 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
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
The main reason for the exception handler in the exception handler would be to handle an array bounds exception on the indexing op. It's not nice to take an (unhandled) exception in an exception handler. On Jan 20, 7:21 am, RyanMcNally therealr...@gmail.com wrote: There's been no indication that the arrays could be null so far, but I guess at this point we are fully through the looking-glass so all bets are off. Welcome to bizarro-world, engage null-checks for your safety, convenience and psychological integrity. Ryan On Jan 20, 1:07 pm, DanH danhi...@ieee.org wrote: You didn't put an exception handler around the subscript operation in the exception handler. On Jan 20, 6:38 am, RyanMcNally therealr...@gmail.com wrote: No native code I'm afraid. I've given the three users apk's with the improved exception logging, and so begins the waiting game... Ryan On Jan 20, 1:12 am, fadden fad...@android.com wrote: That is definitely strange. I can't see any reason why that exception would be thrown from that point. If you suspect that the object has been damaged, there's an excellent chance that your improved exception handler will throw an exception. Or crash. Either way you will have learned something new. :-) Future versions of the VM do show additional detail on array index problems. Is there any native code involved? JNI code can generate array bounds exceptions, and if somebody crossed up JNIEnv* it could end up on the wrong thread. Of course, it's *highly* unlikely that multiple occurrences on different devices would have the same stack trace if the failure is actually happening elsewhere. There are no exceptions involved in floating-point division by zero on Android (other than whatever the VFP hardware does internally). -- 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
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
Only a blind shot: Did you check whether another instance of frustrum is used? Like e.g. an accidental float[][] frustrum = ... in the function or maybe even an if block or something similar, so a local instance is used instead of the class member, parameter, or whatever was intented. However, I once had very similar troubles, though with an Array instance instead of a native array. One day I added lots of additional checks and Log.d to find the error, but after this, the error just vanished without any of the checks becoming active. No idea what happened there... -- 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
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
(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 news 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.
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
Unfortunately, division by zero does not raise an exception at all - you just get infinity as a result. I would be utterly appalled if there was anything remotely fuzzy about how exceptions are raised, but it would certainly be an explanation for this situation Cheers! On Jan 18, 9:51 pm, DanH danhi...@ieee.org wrote: I'm betting you're getting a divide-by-zero and the wrong exception is being raised, due to near proximity of the two tests and some likely fuzzy machine level exception resolution logic. On Jan 18, 7: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) at com.ryanm.droid.rugl.util.FPSCamera.setPosition(FPSCamera.java:174) at com.ryanm.minedroid.BlockView.draw(BlockView.java:318) at com.ryanm.droid.rugl.Game.onDrawFrame(Game.java:247) at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java: 1332) at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1116) ... You can view the offending file here:http://code.google.com/p/rugl/source/browse/trunk/droid/DroidRUGL/src... 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 news 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
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
Does anyone have any suggestions on what diagnostics to add? The code is statically verifiable not to throw AIOOBEs, so I've got no idea what to check for at runtime. Given that there is no threading, the arrays are defined exactly once, and the same indices are successfully written to 8 lines earlier and read from 2 lines earlier, I don't know what to check for. On Jan 18, 10:07 pm, Frank Weiss fewe...@gmail.com wrote: I suggest catching the AIOBE and adding your own diagnostics, via a toast, log, or analytics code. -- 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
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
On Jan 19, 8:26 am, mort m...@sto-helit.de wrote: Only a blind shot: Did you check whether another instance of frustrum is used? Like e.g. an accidental float[][] frustrum = ... in the function or maybe even an if block or something similar, so a local instance is used instead of the class member, parameter, or whatever was intented. There are only 4 occurrences of new in the file, the 4 at the top declaring the class fields. Also, hitting F3 on the frustum on line 180 in eclipse takes you to the field declaration as expected. I'm as sure as I can be that it's not a variable scope error. However, I once had very similar troubles, though with an Array instance instead of a native array. One day I added lots of additional checks and Log.d to find the error, but after this, the error just vanished without any of the checks becoming active. No idea what happened there... Ah yes, the venerable heisenbug, scourge of programmers everywhere... Thanks to all for their thoughts, it at least appears that this is not embarrassingly obviously my fault, so I'm taking that as a step forward! -- 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
Re: [android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
I would try moving the initialization of frustum into the constructor, and add log statements for array size(s) in the method. BTW, you said, no threading - but don't you have a separate rendering thread? -- Kostya 19.01.2011 13:35, RyanMcNally пишет: Does anyone have any suggestions on what diagnostics to add? The code is statically verifiable not to throw AIOOBEs, so I've got no idea what to check for at runtime. Given that there is no threading, the arrays are defined exactly once, and the same indices are successfully written to 8 lines earlier and read from 2 lines earlier, I don't know what to check for. On Jan 18, 10:07 pm, Frank Weissfewe...@gmail.com wrote: I suggest catching the AIOBE and adding your own diagnostics, via a toast, log, or analytics code. -- Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- 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
Re: [android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
Ok its statically verifiable. I still suggest try catching the exception and logging diagnostics. On Jan 19, 2011 2:35 AM, RyanMcNally therealr...@gmail.com wrote: Does anyone have any suggestions on what diagnostics to add? The code is statically verifiable not to throw AIOOBEs, so I've got no idea what to check for at runtime. Given that there is no threading, the arrays are defined exactly once, and the same indices are successfully written to 8 lines earlier and read from 2 lines earlier, I don't know what to check for. On Jan 18, 10:07 pm, Frank Weiss fewe...@gmail.com wrote: I suggest catching the AIOBE and adding your own diagnostics, via a toast, log, or analytics code. -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- 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
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
The frustum object is constructed in the main UI thread, from then on it's only touched in the rendering callback methods, which are all on the same thread. On Jan 19, 10:46 am, Kostya Vasilyev kmans...@gmail.com wrote: I would try moving the initialization of frustum into the constructor, and add log statements for array size(s) in the method. BTW, you said, no threading - but don't you have a separate rendering thread? -- Kostya 19.01.2011 13:35, RyanMcNally пишет: Does anyone have any suggestions on what diagnostics to add? The code is statically verifiable not to throw AIOOBEs, so I've got no idea what to check for at runtime. Given that there is no threading, the arrays are defined exactly once, and the same indices are successfully written to 8 lines earlier and read from 2 lines earlier, I don't know what to check for. On Jan 18, 10:07 pm, Frank Weissfewe...@gmail.com wrote: I suggest catching the AIOBE and adding your own diagnostics, via a toast, log, or analytics code. -- Kostya Vasilyev -- WiFi Manager + pretty widget --http://kmansoft.wordpress.com -- 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
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
I'll give it a shot. I've wrapped the whole method in
try
{
...
}catch( Exception e )
{
StringBuilder b = new StringBuilder();
b.append( modl.length = ).append( modl.length );
b.append( \nproj.length = ).append( proj.length );
b.append( \nfrustum.length = ).append( frustum.length );
for( int i = 0; i frustum.length; i++ )
{
b.append( \n\tfrustum[ ).append( i ).append( ].length = )
.append( frustum[ i ].length );
}
throw new RuntimeException( b.toString(), e );
}
I'll send this to the reporting users, see what they can come up with.
Can anyone think of anything else worth logging?
Cheers!
Ryan McNally
On Jan 19, 12:27 pm, Frank Weiss fewe...@gmail.com wrote:
Ok its statically verifiable. I still suggest try catching the exception and
logging diagnostics.
On Jan 19, 2011 2:35 AM, RyanMcNally therealr...@gmail.com wrote:
Does anyone have any suggestions on what diagnostics to add? The code
is statically verifiable not to throw AIOOBEs, so I've got no idea
what to check for at runtime.
Given that there is no threading, the arrays are defined exactly once,
and the same indices are successfully written to 8 lines earlier and
read from 2 lines earlier, I don't know what to check for.
On Jan 18, 10:07 pm, Frank Weiss fewe...@gmail.com wrote:
I suggest catching the AIOBE and adding your own diagnostics, via a
toast,
log, or analytics code.
--
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.comandroid-developers%2Bunsubs
cr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
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
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
What I would do is add, just ahead of the offending statement, code that tests every reasonable possibility separately. Eg, check T for zero and verify that you can divide a typical number by it (*), access just frustum[3] and assign it to a variable, then access element zero from there. And any other variations you can think of. (*) Even though Java defines floating-point division by zero to produce infinity, often that's handled under the covers by an exception handler. On Jan 19, 4:35 am, RyanMcNally therealr...@gmail.com wrote: Does anyone have any suggestions on what diagnostics to add? The code is statically verifiable not to throw AIOOBEs, so I've got no idea what to check for at runtime. Given that there is no threading, the arrays are defined exactly once, and the same indices are successfully written to 8 lines earlier and read from 2 lines earlier, I don't know what to check for. On Jan 18, 10:07 pm, Frank Weiss fewe...@gmail.com wrote: I suggest catching the AIOBE and adding your own diagnostics, via a toast, log, or analytics code. -- 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
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
You had better wrap .append( frustum[ i ].length ); with an
exception handler.
On Jan 19, 7:15 am, RyanMcNally therealr...@gmail.com wrote:
I'll give it a shot. I've wrapped the whole method in
try
{
...}catch( Exception e )
{
StringBuilder b = new StringBuilder();
b.append( modl.length = ).append( modl.length );
b.append( \nproj.length = ).append( proj.length );
b.append( \nfrustum.length = ).append( frustum.length );
for( int i = 0; i frustum.length; i++ )
{
b.append( \n\tfrustum[ ).append( i ).append( ].length =
)
.append( frustum[ i ].length );
}
throw new RuntimeException( b.toString(), e );
}
I'll send this to the reporting users, see what they can come up with.
Can anyone think of anything else worth logging?
Cheers!
Ryan McNally
On Jan 19, 12:27 pm, Frank Weiss fewe...@gmail.com wrote:
Ok its statically verifiable. I still suggest try catching the exception and
logging diagnostics.
On Jan 19, 2011 2:35 AM, RyanMcNally therealr...@gmail.com wrote:
Does anyone have any suggestions on what diagnostics to add? The code
is statically verifiable not to throw AIOOBEs, so I've got no idea
what to check for at runtime.
Given that there is no threading, the arrays are defined exactly once,
and the same indices are successfully written to 8 lines earlier and
read from 2 lines earlier, I don't know what to check for.
On Jan 18, 10:07 pm, Frank Weiss fewe...@gmail.com wrote:
I suggest catching the AIOBE and adding your own diagnostics, via a
toast,
log, or analytics code.
--
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.comandroid-developers%2Bunsubs
cr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
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
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
I'm kind of curious as to why you don't just copy the left, top, and near planes from the right, bottom, and far planes, vs recalculating the identical results. On Jan 18, 7: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) at com.ryanm.droid.rugl.util.FPSCamera.setPosition(FPSCamera.java:174) at com.ryanm.minedroid.BlockView.draw(BlockView.java:318) at com.ryanm.droid.rugl.Game.onDrawFrame(Game.java:247) at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java: 1332) at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1116) ... You can view the offending file here:http://code.google.com/p/rugl/source/browse/trunk/droid/DroidRUGL/src... 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 news 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
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
That is definitely strange. I can't see any reason why that exception would be thrown from that point. If you suspect that the object has been damaged, there's an excellent chance that your improved exception handler will throw an exception. Or crash. Either way you will have learned something new. :-) Future versions of the VM do show additional detail on array index problems. Is there any native code involved? JNI code can generate array bounds exceptions, and if somebody crossed up JNIEnv* it could end up on the wrong thread. Of course, it's *highly* unlikely that multiple occurrences on different devices would have the same stack trace if the failure is actually happening elsewhere. There are no exceptions involved in floating-point division by zero on Android (other than whatever the VFP hardware does internally). -- 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
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
(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 news 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
[android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
I'm betting you're getting a divide-by-zero and the wrong exception is being raised, due to near proximity of the two tests and some likely fuzzy machine level exception resolution logic. On Jan 18, 7: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) at com.ryanm.droid.rugl.util.FPSCamera.setPosition(FPSCamera.java:174) at com.ryanm.minedroid.BlockView.draw(BlockView.java:318) at com.ryanm.droid.rugl.Game.onDrawFrame(Game.java:247) at android.opengl.GLSurfaceView$GLThread.guardedRun(GLSurfaceView.java: 1332) at android.opengl.GLSurfaceView$GLThread.run(GLSurfaceView.java:1116) ... You can view the offending file here:http://code.google.com/p/rugl/source/browse/trunk/droid/DroidRUGL/src... 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 news 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
Re: [android-developers] Re: The curious case of the impossible ArrayIndexOutOfBoundsException
I suggest catching the AIOBE and adding your own diagnostics, via a toast, log, or analytics code. -- 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
