On Aug 14, 2012, at 2:06 PM, "Breyer, Christian" <bre...@initions.com> 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
Monodroid@lists.ximian.com

UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid

Reply via email to