[MonoTouch] Still IntPtr Constructor issues

[Rolf Bjarne Kvinge]

Hi,

On Wed, Dec 7, 2011 at 11:24 PM, Rene Ruppert
<rene.ruppert at googlemail.com>wrote:

> Thanks Rolf! I tried that! Here is the result. But I'm none wiser! It is
> supposed to relayout, I can relayout, but why does it go for the IntPtr
> ctor? What is thie "_createPreparedCellForGlobalRow" about?
> My "fix" is: if the IntPtr ctor is called, I set a bool to indicate the
> cell if in invalid state. When dequeing cells, I check if the cell is NULL
> or that bool is set. In both cases I create a new instance of the cell and
> everything works fine. But still I would like to know if somebody can make
> sense from the debugger output:
>
> #0  0x933b583e in __psynch_cvwait ()
> #1  0x9a6aae21 in _pthread_cond_wait ()
> #2  0x9a65b42c in pthread_cond_wait$UNIX2003 ()
> #3  0x00104188 in suspend_current () at debugger-agent.c:2375
> #4  0x00105da6 in process_event (event=EVENT_KIND_BREAKPOINT,
> arg=0xa1ac33c, il_offset=0, ctx=0xbfffca08, events=0x0, suspend_policy=2)
> at debugger-agent.c:3017
> #5  0x001080c4 in process_breakpoint_inner (tls=0x9c78f10, ctx=0xbfffca08)
> at debugger-agent.c:3837
> #6  0x00108199 in process_breakpoint () at debugger-agent.c:3855
> #7  0xbfffc6c8 in ?? ()
> #8  0x10a7e06f in ?? ()
> #9  0x00011aef in mono_jit_runtime_invoke (method=0xa1ac33c,
> obj=0x9ae7cc0, params=0xbfffcb60, exc=0x0) at mini.c:5770
> #10 0x0022011a in mono_runtime_invoke (method=0xa1ac33c, obj=0x9ae7cc0,
> params=0xbfffcb60, exc=0x0) at object.c:2757
> #11 0x002ee535 in monotouch_trampoline ()
>

So the issue here is that setSelected is called on a native object instance
that doesn't have a corresponding managed peer (as mentioned earlier, this
happens if the managed peer has been freed). This is the reason for
MonoTouch calling the IntPtr ctor (since it can't distinguish between the
case when there has never existed a managed peer, and when the managed peer
was freed by the GC) - MonoTouch tries to construct the managed peer
thinking that it has never existed (and this is done with an IntPtr ctor).

The most usual reason for this problem with tableviewcells is to return
cells from the TableSource's GetCell method without storing those cell
object instances somewhere the managed GC can see them (so from the GC's
point of view they can be freed as soon as the GetCell method returns). The
usual fix is to store created cells in a class-level list.

Rolf


> #12 0x0248e852 in -[UITableViewCell setSelected:] ()
> #13 0x0234044d in -[UITableView(UITableViewInternal)
> _createPreparedCellForGlobalRow:withIndexPath:] ()
> #14 0x02340589 in -[UITableView(UITableViewInternal)
> _createPreparedCellForGlobalRow:] ()
> #15 0x0232bdfd in -[UITableView(_UITableViewPrivate)
> _updateVisibleCellsNow:] ()
> #16 0x0233a851 in -[UITableView layoutSubviews] ()
> #17 0x022e5322 in -[UIView(CALayerDelegate) layoutSublayersOfLayer:] ()
> #18 0x012d8e72 in -[NSObject performSelector:withObject:] ()
> #19 0x0427592d in -[CALayer layoutSublayers] ()
> #20 0x0427f827 in CA::Layer::layout_if_needed ()
> #21 0x04205fa7 in CA::Context::commit_transaction ()
> #22 0x04207ea6 in CA::Transaction::commit ()
> #23 0x04207580 in CA::Transaction::observer_callback ()
> #24 0x012ab9ce in
> __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
> #25 0x01242670 in __CFRunLoopDoObservers ()
> #26 0x0120e4f6 in __CFRunLoopRun ()
> #27 0x0120ddb4 in CFRunLoopRunSpecific ()
> #28 0x0120dccb in CFRunLoopRunInMode ()
> #29 0x0489f879 in GSEventRunModal ()
> #30 0x0489f93e in GSEventRun ()
> #31 0x022a6a9b in UIApplicationMain ()
> #32 0x0cfdcb0d in ?? ()
> #33 0x0cfdb2f0 in ?? ()
> #34 0x0cfdafe8 in ?? ()
> #35 0x0cfdb13e in ?? ()
> #36 0x00011aef in mono_jit_runtime_invoke (method=0xa9e5e2c, obj=0x0,
> params=0xbffff158, exc=0x0) at mini.c:5770
> #37 0x0022011a in mono_runtime_invoke (method=0xa9e5e2c, obj=0x0,
> params=0xbffff158, exc=0x0) at object.c:2757
> #38 0x00222e51 in mono_runtime_exec_main (method=0xa9e5e2c,
> args=0xcd52960, exc=0x0) at object.c:3940
> #39 0x00222061 in mono_runtime_run_main (method=0xa9e5e2c, argc=0,
> argv=0xbffff300, exc=0x0) at object.c:3562
> #40 0x000ad6df in mono_jit_exec (domain=0x9a6fe00, assembly=0x997d1c0,
> argc=1, argv=0xbffff2fc) at driver.c:1102
> #41 0x002f41ca in main ()
>
>
> René
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monotouch/attachments/20111208/a73520db/attachment.html