Bug 11657 - NSValue.FromCATransform3D returning unexpected results
Summary: NSValue.FromCATransform3D returning unexpected results
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: 6.0.x
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2013-04-08 14:38 UTC by Bryan Moulton
Modified: 2013-12-05 18:34 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:

Description Bryan Moulton 2013-04-08 14:38:11 UTC
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:");

    [System.Runtime.InteropServices.DllImport ("/usr/lib/libobjc.dylib")]
    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;
Comment 1 Bryan Moulton 2013-04-08 14:48:21 UTC
It was noted by Miguel that class_getName is wrong in this case. object_getClassName is correct.
Comment 2 Rolf Bjarne Kvinge [MSFT] 2013-04-08 19:24:00 UTC
Exactly what happens with the above code?

And it looks like the desk # is wrong, #27528 is unrelated.
Comment 3 Bryan Moulton 2013-04-08 21:34:22 UTC
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.
Comment 4 Rolf Bjarne Kvinge [MSFT] 2013-04-29 08:03:52 UTC
Marking as NEEDINFO while waiting for debugging results.
Comment 5 Tim Dawson 2013-04-30 07:01:30 UTC
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
MonoTouch: 6.2.0
iOS: 6.1.2
Hardware: iPad3,6
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
End Exception
Comment 6 Rolf Bjarne Kvinge [MSFT] 2013-05-01 06:45:23 UTC
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).
Comment 7 Tim Dawson 2013-05-01 12:08:03 UTC
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!
Comment 8 PJ 2013-11-19 17:04:43 UTC
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.
Comment 9 PJ 2013-12-05 18:34:52 UTC
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.