On Aug 14, 2012, at 2:06 PM, "Breyer, Christian" <[email protected]> wrote:
> Thanks for your answer. The lref option really helped.
>
> One thing causing a problem is to set the ReplyTo property in a message. The
> Messenger lref never gets destroyed, even though the message is.
>
> Message oSendMessage = Message.Obtain(null, (int)eCommand);
> oSendMessage.Data = oBundle as Bundle;
> oSendMessage.ReplyTo = oClient;
> oClient.Send(oSendMessage);
>
> No matter what, this code - the third line to be precise - doesn't make sense
> anyway. By removing that line, no messenger get stuck in the lref table
> anymore.
it's a bug in the generator: we allocate an lref but don't free it. (Argh!)
[Register ("replyTo")]
public Android.OS.Messenger ReplyTo {
get { /* ... */ }
set {
if (replyTo_jfieldId == IntPtr.Zero)
replyTo_jfieldId = JNIEnv.GetFieldID
(class_ref, "replyTo", "Landroid/os/Messenger;");
JNIEnv.SetField (Handle, replyTo_jfieldId,
JNIEnv.ToLocalJniHandle (value));
}
}
JNIEnv.ToLocalJniHandle() allocates a local ref, but it's never freed. Looks
like I forgot to check field generation 4 months ago...
This has been filed as:
https://bugzilla.xamarin.com/show_bug.cgi?id=6531
So there are two "workarounds":
(1) Don't Do that (bwa-ha-ha-ha-ha)
(2) "Somehow" ensure that the thread setting the Messenger.ReplyTo property
eventually "returns to Java." All threads created by Dalvik that enter managed
code should eventually return to Java code, e.g. the Main thread which invokes
Activity.OnCreate(). Once Activity.OnCreate() completes, execution will return
to the Java thread. Upon returning to Java code from non-Java code, the local
reference table is cleared.
Unfortunately this won't do you any good for threads created by Mono
(System.Threading.Thread, ThreadPool, etc.), as they'll never "return" to Java.
> But I can still see the lref count increasing. It seems odd what the trace is
> saying. It shows -l-, which I assume stands for lref destruction, but
> increases the lref count.
> 08-14 19:35:22.915: I/monodroid-lref(6669): -l- lrefc -14 handle 0xf0b0002d/L
> from at Android.Runtime.JNIEnv.DeleteRef(IntPtr handle, JniHandleOwnership
> transfer)
...
> 08-14 19:35:22.915: I/monodroid-lref(6669): -l- lrefc -15 handle 0xa2700029/L
> from at Java.Interop.TypeManager.CreateInstance(IntPtr handle,
> JniHandleOwnership transfer, System.Type targetType)
Look carefully: the count is _negative_, and decrements from -14 to -15. As I
said, lref counting is rather flaky at the moment...
Thanks,
- Jon
_______________________________________________
Monodroid mailing list
[email protected]
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
