There have been several mentions of runtime aborts that do not contain a stack
trace, e.g.
http://lists.ximian.com/pipermail/monodroid/2011-December/007756.html
http://lists.ximian.com/pipermail/monodroid/2011-December/007862.html
We have discovered a [0] cause: stack overflow.
Mono/ARM has no stack overflow support at the moment, so mono aborts on stack
overflow. (Mono usually aborts _anyway_, but usually you'll at least get some
stack trace output because of it. Mono/ARM does not. We will be improving this
in a future release.)
Combined with a breaking change in Mono for Android 4.0, in which
Java.Lang.Object.Dispose() was made non-virtual and a virtual
Java.Lang.Object.Dispose(bool) method was added, it is now very easy to trigger
stack overflow. Consider:
class Death : Java.Lang.Object {
protected override void Dispose (bool disposing)
{
Android.Util.Log.Info ("death", "Death.Dispose(bool)");
base.Dispose (); // BAD
}
}
If you create and dispose of an instance of Death:
using (var f = new Death ()) {
}
then your app will crash with a stack overflow, and no stack trace will be
printed. (You will get a ton of "Death.Dispose(bool)" messages printed to
logcat, but most Dispose() implementations won't actually log anything...hence
the stacktrace-less nature of the abort.)
The solution is to review any Java.Lang.Object.Dispose(bool) overrides and
ensure that IF they call base.Dispose(), they call the Dispose(bool) method,
NOT Dispose():
base.Dispose(disposing); // GOOD
base.Dispose(); // BAD
This is in accordance with the IDisposable pattern:
http://msdn.microsoft.com/en-us/library/b1yfkh5e.aspx
- Jon
[0] I have no idea if it's _the_ cause, but it's certainly _a_ cause. I'm
always interested in further repros.
_______________________________________________
Monodroid mailing list
[email protected]
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
