Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 6721 [details]
I get the following exception after updating to iOS 22.214.171.124
The object was used after being disposed.
at MonoTouch.Foundation.NSObject.get_SuperHandle () [0x00015] in /Developer/MonoTouch/Source/maccore/src/Foundation/NSObject2.cs:328
at MonoTouch.UIKit.UIControl.set_Enabled (Boolean value) [0x0002b] in /Developer/MonoTouch/Source/monotouch/src/build/compat/UIKit/UIControl.g.cs:323
at SampleProj.Sample.ToggleManualMode (System.Object sender, System.EventArgs e) [0x0001a] in /Users/John/Downloads/SampleProj/SampleProj/Sample.cs:45
Steps to Reproduce:
1. Run the attached sample
2. Touch the UISwitch to "Enable the button".
Exception is thrown.
User who reported this issue did not notice the same exception on previous version of Xamarin.iOS using the same code.
> User who reported this issue did not notice the same exception on previous
> version of Xamarin.iOS using the same code.
That's correct. This check was added recently, i.e. it was not in older version of XI. The older XI could call a *_msgSendSuper_* with an invalid "SuperHandle" if the object was disposed.
What would happen at runtime is undefined (could be ignored, it could corrupt state/memory or it could crash) depending on the code being called. IOW nothing XI could do about - except avoid calling the code with an invalid handle (which is what we now do).
The new check/exception makes it clear where (and when) it happens. That nice because any corruption could go unnoticed for quite some time and cause random failures later, which makes debugging such bugs very hard.
OTOH it's possible that a "ignored" call (or unnoticed corruption) will make "working" code throw such an exception. In such case the (user) code needs to be fixed.
I cannot duplicate the issue with the attached sample. Not with the provided instructions (should be very simple), not with trying other things.
We have not received the requested information. If you are still experiencing this issue please provide all the requested information and re-open the bug report. Thanks!