This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 6264 - Selector invoked from objective-c on a managed object that has been GC'ed
: Selector invoked from objective-c on a managed object that has been GC'ed
Status: RESOLVED FIXED
Product: iOS
Classification: Xamarin
Component: Runtime
: 5.2
: Macintosh Mac OS
: --- normal
: Untriaged
Assigned To: Rodrigo Kumpera
:
:
:
:
  Show dependency treegraph
 
Reported: 2012-07-24 18:13 EDT by Jonas Sourlier
Modified: 2013-06-10 16:08 EDT (History)
7 users (show)

See Also:
Tags:
Test Case URL:
External Submit: ---


Attachments
Test project to reproduce the bug (13.73 KB, application/zip)
2012-07-24 18:13 EDT, Jonas Sourlier
Details

Description Jonas Sourlier 2012-07-24 18:13:26 EDT
Created attachment 2251 [details]
Test project to reproduce the bug

See the attachment, it's a simple MonoTouch project that reproduces the bug.
Steps to reproduce:

1) Start the app
2) Press the button
3) Press the back button to navigate back
4) Repeat steps 2 and 3 until the crash occurs (usually in 5-15 seconds)

The first view controller creates a new instance of the ChildView controller
every time the button is pressed (step 2). The old instance of the ChildView is
nulled, so it can be garbage collected, since it is not anymore used by iOS.
However, it seems that iOS keeps a reference to the old ChildView instances,
because when a 'didReceiveMemoryWarning' is simulated in AppDelegate.cs, the
app crashes since the managed ChildView instances have already been GC'ed.

See the following discussion on Stackoverflow:
http://stackoverflow.com/questions/11609353/release-dispose-of-a-uiviewcontroller-in-monotouch
Comment 1 Rolf Bjarne Kvinge 2012-07-25 10:14:18 EDT
This actually looks like a GC (boehm) bug, it's not handling resurrecting
weakrefs properly.

Sgen seems to work just fine.

Rodrigo, it looks like the gc clears out the target for resurrecting weakrefs
before the dtor is called, so our intptr-nsobject mapping doesn't quite work as
expected.
Comment 2 Sebastien Pouliot 2012-07-27 14:25:11 EDT
This is easy to duplicate (less than 30 secs) on 5.2.x but I could not
duplicate it (after a few mins) on master. Boehm used in both cases.

5.2-series does not have the MonoTouch_Disposer IntPtr->NSObject fix.
Comment 3 Sebastien Pouliot 2012-07-27 16:16:23 EDT
nm comment #2, testing an (unrelated) mtouch fix using the same solution just
crashed it
Comment 4 Jonas Sourlier 2012-08-14 03:42:37 EDT
Anybody knows if this is related to the critical update announced on August 13
on http://blog.xamarin.com ? The description there sounds like it could be
related.
Comment 5 Sebastien Pouliot 2012-08-14 08:27:51 EDT
Jonas, No this is not related. The next MonoTouch release (5.3.6) will provide
more information on this issue (i.e. a more complete exception message) to ease
finding where those comes from.
Comment 6 Jonas Sourlier 2012-08-14 08:33:33 EDT
Thank you Sebastien!
Comment 7 Miguel de Icaza 2012-10-19 16:34:40 EDT
We have posted an update that could help in this situation, would you be so
kind to download the binaries in this page (it contains a description of the
changes) and report whether this solves the problem?

https://docs.google.com/a/xamarin.com/document/d/1o3FQ-2oxF-v85iAIAr6rsIGSgQ-eSUUteozJe7C5fWE/edit
Comment 8 Miguel de Icaza 2012-11-06 15:05:44 EST
Opening the hidden comment, to expand testing.
Comment 10 Rodrigo Kumpera 2013-06-10 16:08:16 EDT
The fix has been back ported to 2.10. It's now a matter of landing it to a
stable product.

Note You need to log in before you can comment on or make changes to this bug.