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
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.
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
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,
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
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
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
(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
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
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
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
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
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
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
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 =
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
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();
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,
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
(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
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
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
22 matches
Mail list logo
