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.
In reference to case #27528
User is reporting InvalidCastException when calling NSValue.FromCATransform3D. It has been determined that the problem lies between the native return value from ValueWithCATransform3D and Runtime.GetNSObject. The value coming from GetNSObject is currently unknown. Attempts to reproduce the case are difficult because it only seems to occur on iPad devices in the field.
Here is user code for FromCATransform3D, which breaks down the process.
public static class NSValueHelper
static IntPtr class_ptr = Class.GetHandle ("NSValue");
static IntPtr selValueWithCATransform3D_ = Selector.GetHandle ("valueWithCATransform3D:");
private static extern IntPtr class_getName (IntPtr cls);
public static NSValue FromCATransform3D(CATransform3D transform)
IntPtr obj = Messaging.IntPtr_objc_msgSend_CATransform3D (class_ptr, selValueWithCATransform3D_, transform);
if (obj == IntPtr.Zero )
throw new Exception("valueWithCATransform3D returned null");
NSObject nso = Runtime.GetNSObject (obj);
if (!(nso is NSValue)) //This is where we are trying to determine the output type
IntPtr cls = class_getName(obj); //Exceptions are thrown here
throw new Exception("valueWithCATransform3D returned object of type: " + new String((sbyte*)cls));
return nso as NSValue;
It was noted by Miguel that class_getName is wrong in this case. object_getClassName is correct.
Exactly what happens with the above code?
And it looks like the desk # is wrong, #27528 is unrelated.
Slight dyslexia there. That's #27258
The code provided errors on class_getName because this is the wrong call. User is going to test with object_getClassName instead and report the results.
Marking as NEEDINFO while waiting for debugging results.
Ok, we're starting to see the first exceptions coming in. I've pasted one below for you. Note that we have turned on extra debugging information including the iOS version and hardward model.
Begin Exception Exception at 2013/04/20 00:14:57
Product: SkyDemon for iPad
Status: Animating Map
System.Exception: valueWithCATransform3D returned object of type: NSConcreteValue
at Divelements.SkyDemon.Mapping.MapView+NSValueHelper.FromCATransform3D (CATransform3D transform) [0x00000] in <filename unknown>:0
at Divelements.SkyDemon.Mapping.MapView.PositionMapLayer (Divelements.SkyDemon.Mapping.ProjectionLayer layer, Divelements.SkyDemon.Mapping.MercatorProjection projection, Divelements.SkyDemon.Mapping.MercatorProjection fromProjection, Double seconds, Boolean flip) [0x00000] in <filename unknown>:0
This is unfortunately once again an "impossible" situation.
Is there anything otherwise in common between the crashes (hardware model / iOS version / physical location)?
I'm lead to believe that you're running into some sort of random memory corruption due to the number of "impossible" situations you're running into. Since these issues are notoriously hard to track down, I could create a instrumented version of Xamarin.iOS (based on the stable version you're using), which may help narrow down where the corruption is occurring (the nasty thing about memory corruption is that you usually see the effect of the corruption much later than when it actually happened, which makes it tricky to track down).
The trouble is, we only see the corruption happening when widely deployed to the public. I wouldn't feel comfortable releasing a build to the public based on an instrumented version of Xamarin.iOS, though I greatly appreciate the offer.
The only unusual thing about our build is that we're using sgen. I've started wondering if that might be responsible for all these impossible problems we're having, so I've switched back to the other one and will do our next public release using that, assuming no stability problems are discovered by our beta testers in the meantime.
I will report back with the results. If it does solve the problem, at least you would know there are significant stability issues with sgen!
This bug has been in the NEEDINFO state with no changes for the last 90 days. Can we put this back into the NEW or CONFIRMED state, or are we still awaiting response?
If there is no change in the status of this bug over the next two weeks, this bug will be marked as NORESPONSE.
This bug has not been changed from the NEEDINFO state since my previous comment, marking as RESOLVED NORESPONSE.
Please feel free to REOPEN this bug at any time if you are still experiencing the issue. Please add the requested information and set the bug back to the NEW (or CONFIRMED) state.