[MonoTouch] Still IntPtr Constructor issues

[Rolf Bjarne Kvinge]

On Fri, Dec 9, 2011 at 8:58 AM, René Ruppert <rene.ruppert at googlemail.com>wrote:

> In my case the weird thing is that the issues seem to show 99% on the
> device and there mainly on iPad 1 and not do often on iPad 2. In the
> simulator I was able to reproduce almost never. Only after setting up a
> timer with an interval of 20ms(!!) it happened sometimes in the sim and
> often enough on iPad 2.  So i assume it is a parallel execution and/or
> timing issue. Maybe you have an idea for future improvements based on this
> observation?
>

Are you using GC.Collect (GC.MaxGenerations)? Do you do any work on
separate threads? I find it quite strange that it's not very reproducible,
these bugs usually are quite reproducible, at least on the simulator.

Rolf


>
> Grüße, René
>
> Am 08.12.2011 um 22:19 schrieb Rolf Bjarne Kvinge <rolf at xamarin.com>:
>
> Hi René,
>
> On Thu, Dec 8, 2011 at 5:40 PM, René Ruppert <rene.ruppert at googlemail.com>wrote:
>
>> Thanks for this detailed answer. Is there a list of cases that show when
>> I will have to keep explicit refs? You should know best where things can go
>> wrong.
>>
>
> Unfortunately it's not possible to have an exhaustive list of cases, since
> the iOS API is quite big. As a general rule you need to keep explicit
> references to framework objects (instances of framework types you haven't
> subclassed, for instance UITableViewCell). In some cases MonoTouch will add
> that explicit reference for you (it depends on the API, sometimes we can't
> add explicit references because of how the API is bound, in some cases
> because we don't know when we'd have to clear that explicit reference). In
> any case issues tend to show themselves pretty quickly in the simulator
> (since we've made the GC very aggressive there exactly to catch issues like
> these), and you'll usually be able to tell at least the type of the object
> that's been freed (that's the exception about the IntPtr ctor).
>
> Please announce once you have that document ready that explains the
>> changes. Miguel said you are working on a concept that will fix all of
>> these problems. Is this the same topic?
>>
>
> Yes, it is.
>
>
>> As for releasing the references: if the view that is using the cells is
>> managed by a controller, is my assumption correct that I do not need to
>> release them explicitly if I hold them in the view itself? I mean, if the
>> view is unloaded it should get GC'd together with the cells.
>>
>
> If you have a (managed) list of cells in a view, and that view is freed by
> the GC, then the list (and its items) will be freed too (note that the fact
> that a view is unloaded doesn't necessarily mean that the view can be
> collected from the GC's point of view (even though that's generally true),
> you might have a reference to the view somewhere else - what you can do
> though is to clear the list of cells in the ViewDidUnload method).
>
> Best regards,
> Rolf
>
>
>>
>> Grüße, René
>>
>> Am 08.12.2011 um 16:56 schrieb Rolf Bjarne Kvinge <rolf at xamarin.com>:
>>
>> On Thu, Dec 8, 2011 at 1:52 AM, Rene Ruppert <rene.ruppert at googlemail.com
>> > wrote:
>>
>>> But isn't that then,like Miguel said, an issue of Monotouch? Shouldn't
>>> it keep a reference?
>>> I have not seen a single MT example so far tat keeps explicit references
>>> to table view cells. Are they all wrong?
>>>
>>
>> It's actually quite a tricky subject, we've tried a lot of possible
>> solutions and we've come to the conclusion that it's virtually impossible
>> to make it perfect (which is that managed code should not need to hold
>> objects alive manually and at the same time no objects should be leaked).
>> We have improved some scenarios (included in the current v5.1.1 beta, but
>> it has to be enabled manually), and we're working on documentation
>> explaining exactly what has been improved.
>>
>> Returning to your particular problem: in theory it should work if you
>> subclass UITableViewCell (which you do) - in which case the object is kept
>> alive while native code has a ref. Unfortunately objc might not keep a ref
>> in all cases (for instance look at assign setter semantics here:
>> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocProperties.html#//apple_ref/doc/uid/TP30001163-CH17-SW2),
>> which I suspect is what's happening to you. It is however hard to find the
>> exact cause without a sample we can run ourselves.
>>
>> Keeping an explicit ref to table view cells is a pretty easy workaround
>> (and it doesn't suffer from the undefined behavior adding the IntPtr ctor
>> would have). The problem is of course to know when to remove the explicit
>> ref - but in my experience you don't end up with that many table view cell
>> instances if you reuse them (and just release the explicit ref when the
>> corresponding view is unloaded).
>>
>> I hope this helps,
>> Rolf
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monotouch/attachments/20111209/511d5920/attachment-0001.html