Thanks for the swift reply Jon. Much obliged for your input to the problem.
Interesting update is that I also get a similar stacktrace from the string
concatenation which happens in the WriteLine just before the clipping. It
is consistently failing this way and doesn't take very long to happen
either. Again that suggests it's just that string that's being hosed by
something.
I changed all libs to build as 2.2 and the exception still happens, so it's
not a version problem. I shall take your good advice on this one though and
refrain from such a setup in future :)
I checked and those empty exception blocks you mention are not being called.
However I can't guarantee that exceptions are not being caught elsewhere in
the application's network stack. The code's pretty extensive and it would
be a pretty big job to go through it with a fine tooth comb to weed these
out and count them. I will try 1.9.1 and see how I get on next week to rule
out this issue.
Regarding exception handling, I'm not entirely sure what you mean by
Java->managed invocations, and whether these apply in this case, but aside
from the UI thread and a broadcast receiver handling wifi state changes,
both of which are not doing any exception handling, I can only tell you
that all code is executing on mono threads which have been spawned from a
mono thread within the OnCreate override of a local service, basically like
the following:
public override void OnCreate()
{
base.OnCreate();
Thread t = new Thread(new ThreadStart(() =>
{
try
{
InitialiseStack(); // spawns several comms threads,
timers etc.
}
catch (Exception ex)
{
UserLog.WriteLine("Initialise stack:: " + ex);
}
}));
t.Start();
}
The user log is being appended by a timer callback. Again, don't know if
this qualifies it as a Java->managed invocation... Other threads could
write to the userlog at the same time, so I can't rule out failure of the
lock for certain, but I hammered a test app pretty extensively and couldn't
reproduce it. I don't think a bug in critical sections is a very likely
explanation anyway. It just seems too far fetched really.
Why it is this object in particular, and consistely so, is a bit of a
mystery but as a shot in the dark, and I confess my knowledge of garbage
collection internals is extremely sketchy :), could it be a GC/large object
heap related issue? The string would be 32767 characters long, which would
possibly just qualify it for this heap. Collected too early perhaps? The
full application would have a lot more memory pressure than my toy threading
app (we retain a lot of xml for every device on the network), which might
explain why it is happening in the real app?
What do you think?
Cheers
Iain
ps Apologies if this reply doesn't make it back as part of the original
thread of discussion. I'm using gmail and couldn't get the in-reply-to
header.
>On Oct 7, 2011, at 7:18 AM, Iain Mcleod wrote:
>>* Weird and rather worrying. I cannot explain this stacktrace at all as
the UserLog class is thread safe as far as I can see and in fact has been in
production across multiple platforms for years.*
>>* Sorry, I don't have the actual exception message, there did not appear
to be one in the logcat output.*
>I see lots of `catch(Exception){}` blocks. Do you know how many exceptions
are being generated, if any?
>I ask because there was a Local Reference leak (fixed in 1.9.1) around
exception handling. If you're not throwing exceptions, this shouldn't be an
issue, but if you are, and you never return to Java code (assuming a
Java->managed invocation, which wouldn't be the case for managed threads),
then you could run out of Local References.
>* Only slightly nonstandard thing I can think of is that UserLog is in a
library dll which is built with a minimum target platform version of 1.6
whereas the app was built to target 2.2.*
>This shouldn't be the problem, but don't do that. :-)
>The primary reason we have different versions of Mono.Android.dll is
because android.jar changed in a forward-compatible manner, but not a
backward compatible manner -- some members were moved from a derived class
into an (introduced) base class. This works fine if you're running an older
app on a new Android, but it bombs horribly if you run a newer app against
an older Android (the method doesn't exist!).
>Thus, Mono.Android.dll v1.6 will differ from Mono.Android.dll v2.2, but
only Mono.Android.dll v2.2 will be bundled with your app. This _could_ cause
compatibility problems due to the aforementioned member movement.
>Again, this shouldn't be the cause of your crash, but it's something to
avoid.
> - Jon
_______________________________________________
Monodroid mailing list
[email protected]
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
