Bug 15316 - SIGSEGV in MonoTouch.Foundation.NSObject.ReleaseManagedRef ()
Summary: SIGSEGV in MonoTouch.Foundation.NSObject.ReleaseManagedRef ()
Status: VERIFIED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 7.0.0.x
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2013-10-09 19:10 UTC by Frank A. Krueger
Modified: 2014-11-28 06:47 UTC (History)
8 users (show)

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


Attachments
Sample project producing this error (16.24 KB, application/zip)
2014-08-25 13:06 UTC, Eric Kinoshita
Details


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:
Status:
VERIFIED FIXED

Description Frank A. Krueger 2013-10-09 19:10:20 UTC
I've been getting this crash sporadically since upgrading to the 7.0 MonoTouch (mtouch 7.0.2.7 (57edee2)).

This is with SGEN and Generic Value Type sharing enabled.


Stacktrace:
  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) MonoTouch.Foundation.NSObject.monotouch_release_managed_ref (intptr) <0xffffffff>
  at MonoTouch.Foundation.NSObject.ReleaseManagedRef () [0x00000] in /Developer/MonoTouch/Source/monotouch/src/Foundation/NSObject.cs:99
  at MonoTouch.Foundation.NSObject/NSObject_Disposer.Drain (MonoTouch.Foundation.NSObject) [0x00062] in /Developer/MonoTouch/Source/monotouch/src/shared/Foundation/NSObject2.cs:602
  at (wrapper runtime-invoke) object.runtime_invoke_dynamic (intptr,intptr,intptr,intptr) <0xffffffff>
  at <unknown> <0xffffffff>
  at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication.UIApplicationMain (int,string[],intptr,intptr) <0xffffffff>
  at MonoTouch.UIKit.UIApplication.Main (string[],string,string) [0x0004c] in /Developer/MonoTouch/Source/monotouch/src/UIKit/UIApplication.cs:38
  at Calca.iOS.Application.Main (string[]) [0x00008] in /Users/fak/Dropbox/Projects/Calca/Calca.iOS/Main.cs:17
  at (wrapper runtime-invoke) object.runtime_invoke_dynamic (intptr,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:
	0   Calca                               0x00673b57 mono_handle_native_sigsegv + 254
	1   Calca                               0x0067e635 mono_sigsegv_signal_handler + 176
	2   libsystem_platform.dylib            0x38732723 _sigtramp + 42
	3   UIKit                               0x3084a875 <redacted> + 64
	4   UIKit                               0x305c7905 <redacted> + 604
	5   UIKit                               0x305c7673 <redacted> + 1398
	6   UIKit                               0x3067ae9f <redacted> + 418
	7   UIKit                               0x3067acf7 <redacted> + 30
	8   UIKit                               0x3067acaf <redacted> + 30
	9   UIKit                        	       0x305a8b93 <redacted> + 366
	10  UIKit                               0x3071e1a5 <redacted> + 432
	11  Calca                               0x00725c80 invoke_objc_method_implementation + 156
	12  Calca                               0x00725a64 monotouch_release_trampoline + 192
	13  Calca                               0x007257a8 monotouch_release_managed_ref + 196
	14  Calca                               0x0037a7c0 wrapper_managed_to_native_MonoTouch_Foundation_NSObject_monotouch_release_managed_ref_intptr + 92
	15  Calca                               0x0033986c MonoTouch_Foundation_NSObject_ReleaseManagedRef + 32
	16  Calca                               0x0033b168 MonoTouch_Foundation_NSObject_NSObject_Disposer_Drain_MonoTouch_Foundation_NSObject + 364
	17  Calca                               0x004cf030 wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 200
	18  Calca                               0x006806a5 mono_jit_runtime_invoke + 1112
	19  Calca                               0x006c7fb5 mono_runtime_invoke + 88
	20  Calca                               0x00645fdf native_to_managed_trampoline_MonoTouch_Foundation_NSObject_NSObject_Disposer_Drain + 250
	21  Foundation                          0x2e806fdb <redacted> + 386
	22  CoreFoundation                      0x2ddedf27 <redacted> + 14
	23  CoreFoundation                      0x2dded3ef <redacted> + 206
	24  CoreFoundation                      0x2ddebbdf <redacted> + 630
	25  CoreFoundation                      0x2dd56541 CFRunLoopRunSpecific + 524
	26  CoreFoundation                      0x2dd56323 CFRunLoopRunInMode + 106
	27  GraphicsServices                    0x32a862eb GSEventRunModal + 138
	28  UIKit                               0x3060d1e5 UIApplicationMain + 1136
	29  Calca                               0x0038207c wrapper_managed_to_native_MonoTouch_UIKit_UIApplication_UIApplicationMain_int_string___intptr_intptr + 272
	30  Calca                               0x00345c54 MonoTouch_UIKit_UIApplication_Main_string___string_string + 300
	31  Calca                               0x0013d268 Calca_iOS_Application_Main_string__ + 172
	32  Calca                               0x004cf030 wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 200
	33  Calca                               0x006806a5 mono_jit_runtime_invoke + 1112
	34  Calca                               0x006c7fb5 mono_runtime_invoke + 88
	35  Calca                               0x006cbd45 mono_runtime_exec_main + 292
	36  Calca                               0x006cbb85 mono_runtime_run_main + 424
	37  Calca                               0x0066ab41 mono_jit_exec + 48
	38  Calca                               0x00711468 main + 2480
	39  libdyld.dylib                       0x38619ab7 <redacted> + 2
Comment 1 Rolf Bjarne Kvinge [MSFT] 2013-10-10 06:51:13 UTC
This typically happens when managed code tries to free an object that has already been freed. At least having a complete stack trace (with no <redacted> frames) would help, but a test case would probably be required to track it down.
Comment 2 Frank A. Krueger 2013-10-10 18:21:02 UTC
I can't possibly write a test case for this, it's sporadic. But it happens, a lot.

Please explain to me how to remove the <redacted> frames and I will give a new stack trace the next time it crashes.
Comment 3 Rolf Bjarne Kvinge [MSFT] 2013-10-10 18:22:06 UTC
The crash report from Xcode should resolve the <redacted> frames properly.
Comment 4 Rolf Bjarne Kvinge [MSFT] 2013-10-14 05:37:42 UTC
Are there any specific things I need to do to reproduce this? Any actions in particular you do that triggers it?
Comment 5 Frank A. Krueger 2013-10-14 13:10:34 UTC
I have recovered the redacted frames. Here is the new stack trace.

It would appear that a managed reference is being released, that causes a ViewController to be released, that causes a ScrollView to be released, and then it tries to execute a callback.

Is it possible that _notifyDidScroll is trying to bounce back to mono, or could this be a UIKit bug?

To repro, I think you have to open and close files. Every view controller in the app has a UIScrollView :-( so I'm not sure exactly which one could be causing trouble. But I think it's safe to assume the TableViews are well behaved, so that leaves just my TextEditorController.

	0   Calca                               0x00673b57 mono_handle_native_sigsegv + 254
	1   Calca                               0x0067e635 mono_sigsegv_signal_handler + 176
	2   libsystem_platform.dylib            0x38732723 _sigtramp + 42
	3   UIKit                         	0x3084a871 -[UIScrollView(UIScrollViewInternal) _notifyDidScroll] + 61
	4   UIKit                         	0x305c7901 -[UIScrollView setContentOffset:] + 601
	5   UIKit                         	0x305c766f -[UIScrollView _adjustContentOffsetIfNecessary] + 1395
	6   UIKit                         	0x3067ae9b -[UIScrollView(UIScrollViewInternal) _stopScrollingNotify:pin:tramplingDragFlags:] + 415
	7   UIKit                         	0x3067acf3 -[UIScrollView(UIScrollViewInternal) _stopScrollingNotify:pin:] + 27
	8   UIKit                         	0x3067acab -[UIScrollView removeFromSuperview] + 27
	9   UIKit                         	0x305a8b8f -[UIView dealloc] + 363
	10  UIKit                         	0x3071e1a1 -[UIViewController dealloc] + 429
	11  Calca                               0x00725c80 invoke_objc_method_implementation + 156
	12  Calca                               0x00725a64 monotouch_release_trampoline + 192
	13  Calca                               0x007257a8 monotouch_release_managed_ref + 196
	14  Calca                               0x0037a7c0 wrapper_managed_to_native_MonoTouch_Foundation_NSObject_monotouch_release_managed_ref_intptr + 92
	15  Calca                               0x0033986c MonoTouch_Foundation_NSObject_ReleaseManagedRef + 32
	16  Calca                               0x0033b168 MonoTouch_Foundation_NSObject_NSObject_Disposer_Drain_MonoTouch_Foundation_NSObject + 364
	17  Calca                               0x004cf030 wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 200
	18  Calca                               0x006806a5 mono_jit_runtime_invoke + 1112
	19  Calca                               0x006c7fb5 mono_runtime_invoke + 88
	20  Calca                               0x00645fdf native_to_managed_trampoline_MonoTouch_Foundation_NSObject_NSObject_Disposer_Drain + 250
	21  Foundation                    	0x2e806fd7 __NSThreadPerformPerform + 383
	22  CoreFoundation                	0x2ddedf25 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 13
	23  CoreFoundation                	0x2dded3eb __CFRunLoopDoSources0 + 203
	24  CoreFoundation                	0x2ddebbdb __CFRunLoopRun + 627
	25  CoreFoundation                      0x2dd56541 CFRunLoopRunSpecific + 524
	26  CoreFoundation                      0x2dd56323 CFRunLoopRunInMode + 106
	27  GraphicsServices                    0x32a862eb GSEventRunModal + 138
	28  UIKit                               0x3060d1e5 UIApplicationMain + 1136
	29  Calca                               0x0038207c wrapper_managed_to_native_MonoTouch_UIKit_UIApplication_UIApplicationMain_int_string___intptr_intptr + 272
	30  Calca                               0x00345c54 MonoTouch_UIKit_UIApplication_Main_string___string_string + 300
	31  Calca                               0x0013d268 Calca_iOS_Application_Main_string__ + 172
	32  Calca                               0x004cf030 wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 200
	33  Calca                               0x006806a5 mono_jit_runtime_invoke + 1112
	34  Calca                               0x006c7fb5 mono_runtime_invoke + 88
	35  Calca                               0x006cbd45 mono_runtime_exec_main + 292
	36  Calca                               0x006cbb85 mono_runtime_run_main + 424
	37  Calca                               0x0066ab41 mono_jit_exec + 48
	38  Calca                               0x00711468 main + 2480
	39  libdyld.dylib                       0x38619ab7 <redacted> + 2
Comment 6 Rolf Bjarne Kvinge [MSFT] 2013-10-15 18:08:09 UTC
I've tried flipping through all the Examples, while scrolling random at the same time and the GC running in a loop, and everything worked flawlessly.

Looking at the stack trace, I see a UIScrollView in _notifyDidScroll - which probably corresponds to [ UIScrollViewDelegate scrollViewDidScroll:] (UIScrollViewDelegate.Scrolled in C#). However you don't use any of the UIScrollViewDelegate API as far as I can tell from a quick grep, but you do use (indirectly) UITextViewDelegate (which inherits from UIScrollViewDelegate) - by adding event handlers for some of UITextViewDelegate's events (SelectionChanged, ShouldChangeText).

In short this means you're probably right about this being a freed TextEditorController.

I would probably add a few Console.WriteLines to TextEditorController's ctor and dtor to get a better idea about what's happening (but it gets a bit difficult as I can't reproduce).
Comment 8 George Piva 2013-11-13 14:38:52 UTC
I think I am facing the same issue here. My application is sporadically crashing with the next stack trace:
http://crashes.to/s/8ce631a0dd1

In three weeks it happened more than 400 times.

As Frank said and the report from Crashlytics presented, this issue appears to happen only on iOS7 devices.

I have double checked the code I used to register and unregister for my UITextViews events but they appear to be Ok.

I am also unable to create a test case.

How can I help you guys to figure out what is happening?
Comment 9 Rolf Bjarne Kvinge [MSFT] 2013-11-13 17:29:27 UTC
George: instead of unregistering the events, can you try setting the Delegate property to null for the objects in question?

Unregistering events will not prevent us from listening for notifications from iOS, we'll just not invoke any event handlers when it happens (while setting the Delegate property to null will effectively prevent any notifications from being sent from iOS).
Comment 10 Adam Kemp 2014-07-28 14:26:26 UTC
I am hitting a crash just like this in my application. The native stack trace (form a debug build on the simulator) looks like this:

#0	0x031660b2 in objc_msgSend ()
#1	0x013f2b61 in -[UIView dealloc] ()
#2	0x003403ba in invoke_objc_method_implementation at /Developer/MonoTouch/Source/monotouch/libmonotouch/monotouch-glue.m:1471
#3	0x0034043c in monotouch_dealloc_trampoline at /Developer/MonoTouch/Source/monotouch/libmonotouch/monotouch-glue.m:1514
#4	0x013ef799 in -[UIView release] ()
#5	0x003403ba in invoke_objc_method_implementation at /Developer/MonoTouch/Source/monotouch/libmonotouch/monotouch-glue.m:1471
#6	0x003401ae in monotouch_release_trampoline at /Developer/MonoTouch/Source/monotouch/libmonotouch/monotouch-glue.m:1500
#7	0x0033feae in monotouch_release_managed_ref at /Developer/MonoTouch/Source/monotouch/libmonotouch/monotouch-glue.m:1416
#8	0x11eee104 in 0x11eee104 ()
#9	0x11eee0b4 in 0x11eee0b4 ()
#10	0x1342a020 in 0x1342a020 ()
#11	0x107bdc7e in 0x107bdc7e ()
#12	0x001b6d8a in mono_jit_runtime_invoke at /Developer/MonoTouch/Source/monotouch/builds/simulator86/mono/mini/../../../../../mono/mono/mini/mini.c:6723
#13	0x00256c2f in mono_runtime_invoke at /Developer/MonoTouch/Source/monotouch/builds/simulator86/mono/metadata/../../../../../mono/mono/metadata/object.c:2828
#14	0x0033a078 in monotouch_static_trampoline at /Developer/MonoTouch/Source/monotouch/libmonotouch/./monotouch-trampoline-invoke.inc:1
#15	0x0316867e in +[NSObject performSelector:withObject:] ()
#16	0x00b34ca4 in __NSThreadPerformPerform ()
#17	0x02cde46f in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ ()
#18	0x02cd390d in __CFRunLoopDoSources0 ()
#19	0x02cd2e68 in __CFRunLoopRun ()
#20	0x02cd27eb in CFRunLoopRunSpecific ()
#21	0x02cd261b in CFRunLoopRunInMode ()
#22	0x043ec29c in GSEventRunModal ()
#23	0x043ec0d9 in GSEventRun ()
#24	0x013853d6 in UIApplicationMain ()

We crash in objc_msgSend:
EXC_BAD_ACCESS (code=1, address=0xf000000c)

I poked around a bit in lldb and found this:
(lldb) f
frame #0: 0x031660b2 libobjc.A.dylib`objc_msgSend + 14
libobjc.A.dylib`objc_msgSend + 14:
-> 0x31660b2:  movzwl 0xc(%edx), %eax
   0x31660b6:  andl   %ecx, %eax
   0x31660b8:  shll   $0x3, %eax
   0x31660bb:  addl   0x8(%edx), %eax
(lldb) x/s $ecx
0x02fd637d: "isKindOfClass:"
(lldb) p ((id)$eax)->isa
(Class) $7 = 0xf0000000

It looks like UIView's dealloc method is trying to call isKindOfClass: on an object that has already be deallocated. I'm just speculating, but could it be that the monotouch_dealloc_trampoline is deallocating things before calling the native UIView dealloc method, and maybe that is invalidating some assumptions?

This is easy for me to reproduce within our application, but it's a complex enough code path that I really don't know where to start to try to make a smaller app to reproduce it. I could share (privately) a binary if necessary.

FYI, we are using SGEN with generic value type sharing and without the ref-counting extension.

If I run the same code in a release build on the device the crash looks very similar, but for some reason [UIView dealloc] shows up as redacted. The crash still seems to happen in a call to "isKindOfClass:".
Comment 11 Rolf Bjarne Kvinge [MSFT] 2014-07-29 03:45:59 UTC
@Adam, in the past we've seen some of these crashes when the GC unintentionally runs into implicit assumptions by Apple's (or someone else's) Objective-C code due to not freeing objects in the normal order (i.e. if objects A and B are usually freed in alphabetic order when Objective-C code uses them, the writers of that code will never notice any bugs related to the opposite order. This hits us when the GC decides to free those objects in whatever order it feels like).

In any case a test case would be required to figure out what's wrong, could you please upload yours?
Comment 12 Adam Kemp 2014-07-29 12:36:17 UTC
I would be glad to do that. What exactly do you want me to send? Do you just want the built .app? Device or simulator?
Comment 13 Rolf Bjarne Kvinge [MSFT] 2014-07-29 13:46:21 UTC
@Adam, the source code entire project would by far be the easiest (since usually I'll need to do modifications to your source code, rebuild, and see what happens). Otherwise I can try to see if I can figure something out with the .app (for simulator is probably the easiest to debug).
Comment 14 Adam Kemp 2014-07-29 14:16:27 UTC
Let's start with a binary because to share source I think we would have to deal with updating our NDA, which is a pain.

I just shared a dropbox folder with support@xamarin.com. To reproduce the issue follow these steps:

1. Run the app in the simulator.
2. Tap the New Dashboard button in the top left.
3. Tap the first toolbar icon after the title (just to the left of the camera icon) to show the "Controls and Indicators" palette.
4. Select Indicators.
5. Drag and LED onto the canvas. Do this 10 times so you have a bunch of LEDs.
6. Rapidly tap the Undo button repeatedly.

In the simulator I saw a crash while trying to dealloc an LEDView.
Comment 17 Rolf Bjarne Kvinge [MSFT] 2014-07-31 06:21:44 UTC
@Adam,

It looks like it's a LEDView trying to access an instance of a BulbGlowRadialGradiantDelegate.

You need to make sure that the native LEDView dealloc method can't get a hold of any freed instances of BulbGlowRadialGradiantDelegate - I haven't looked at your code, but one idea might be to null out any relevant fields in LEDView.Dispose.
Comment 18 Adam Kemp 2014-07-31 11:24:53 UTC
That did help, but I had to use a different workaround. BulbGlowRadialGradiantDelegate is not used directly by LEDView, but it is used by a sublayer of LEDView (it is the delegate for a CALayer). If I tried the Dispose suggestion it would look something like this:

public override void Dispose(bool disposing)
{
    _mySubLayer.Delegate = null;
}

That's not safe because _mySubLayer may have already been GCed if disposing is false.

Instead I did this:

public override void WillMoveToWindow(UIWindow window)
{
    if (window != null)
    {
        _mySubLayer.Delegate = new BulbGlowRadialGradiantDelegate(this);
    }
    else
    {
        _mySubLayer.Delegate = null;
    }
}

That fixed the issue. There is one other usage of a CALayerDelegate in this application. I haven't been able to reproduce this crash with that control so far, but it still concerns me. Unfortunately, in that case the delegate is assigned directly by a CALayer subclass, which doesn't have a WillMoveToWindow method. I'm not sure how I would solve the issue in that case (if I did reproduce it) without some refactoring.

Can you tell what the UIView is trying to do with this delegate? Can Xamarin do something to try to make the delegate of a layer outlast the view that the layer is in?
Comment 19 Rolf Bjarne Kvinge [MSFT] 2014-08-01 06:53:40 UTC
@Adam, unfortunately there's no way to specify finalization order for a garbage collection.

One possible approach you could do would be to create a strong GCHandle in your UIView to the CALayerDelegate, and free that GCHandle in your UIView.Dispose override. You also need to make sure the CALayerDelegate has no strong references back to the UIView (otherwise you'd introduce a cycle which would never be freed). For instance the following code:

    _mySubLayer.Delegate = new BulbGlowRadialGradiantDelegate(this);

would introduce a cycle if you stored the 'this' value directly in a BulbGlowRadialGradiantDelegate field (the workaround would be to store it in a WeakHandle field instead).
Comment 20 Adam Kemp 2014-08-01 11:17:12 UTC
There's no way for me to specify an ordering, but your runtime could in theory be smarter about ordering. That's what I was suggesting. It might not be easy, but this kind of issue is extremely difficult for people to debug, and in the end it turns out that nothing we're doing is unreasonable. We're not doing anything wrong. We're just exposing another hole in the way that the Xamarin/mono runtime tries to mix the GC and refcounted worlds. It's getting hard to keep track of all the voodoo we have to learn to make a stable application.
Comment 21 Eric Kinoshita 2014-08-25 13:06:12 UTC
Created attachment 7790 [details]
Sample project producing this error

This sample project produces the SIGSEGV kill, same stacktrace, and similar native stacktrace.

Instructions zipped with the project.
Comment 22 Eric Kinoshita 2014-08-25 13:10:27 UTC
* Discussed with @AdamKemp in the forum: https://forums.xamarin.com/discussion/22727/sigsegv-annoyance-solved-somewhat
Comment 23 Miguel de Icaza [MSFT] 2014-09-08 12:22:15 UTC
This seems like it works on Objective-C by pure chance, because a common idiom there is:

    view.layer.delegate = self

Due to our early lack of protocol support, we did not use this idiom, and instead encouraged this other idiom:

    view.Layer.Delegate = new SomeDelegateSubclass (this);

The same issue would arise in Objective-C if the idiom was used, for exampel to share an implementation:

    view.layer.delegate = SharedDelegateImplemeentation 

One simple fix is to adopt the same Objective-C idiom:

class myview : ICALayerDelegate {
    override .. the methods
}

Then:

    view.Layer.WeakDelegate = this;

That said, since this is a common problem, we will look into a solution to work around this bug on Apple's UIVIew.
Comment 24 Rolf Bjarne Kvinge [MSFT] 2014-11-25 03:31:53 UTC
This was fixed some time ago.

monotouch/master: cc62239d2f7052de7f0244680f5f0f7feb95e21f
Comment 25 Sunil Kumar 2014-11-28 06:47:23 UTC
I have checked this issue and now this is working fine. I am not getting any crash on running the sample attached in comment 21.

I downloaded sample project attached in comment 21 and followed the below steps mentioned in README file:

1. Run the app (on either the simulator or in an actual device)
2. Pick a number in the first view
3. In the second view press "View collatz sequence..."
   		(* the error is not related to the Collatz Conjecture)
4. Go back to the first View
5. Scroll up and down, open other collatz sequences, until GC is triggered
   		(* the message "ThirdViewController - disposing..." will appear in the log)

I am successfully able to run the sample project with above steps.

I got "ThirdViewController - disposing..." in Application Output which generates  after 5Th step as mentioned in README file. After that attached sample project works fine.

Screencast: http://www.screencast.com/t/QlTSpMdocUH

Please let me know if I missed anything to verify this issue.

Hence, as for now I am closing this issue.

Environment info: 
=== Xamarin Studio ===

Version 5.7 (build 596)
Installation UUID: 561c7a69-0a91-4bae-ad7c-f0c79d594337
Runtime:
	Mono 3.12.0 ((detached/b75fa2b)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 312000046

=== Apple Developer Tools ===

Xcode 5.1.1 (5085)
Build 5B1008

=== Xamarin.iOS ===

Version: 8.6.0.5 (Trial Edition)
Hash: 880cc21
Branch: 
Build date: 2014-11-25 12:12:17-0500

=== Xamarin.Android ===

Version: 5.0.0.0 (Trial Edition)
Android SDK: /Users/tajinder/Desktop/android-sdk-macosx
	Supported Android versions:
		2.3    (API level 10)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
		5.0    (API level 21)
Java SDK: /usr
java version "1.7.0_67"
Java(TM) SE Runtime Environment (build 1.7.0_67-b01)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

=== Xamarin.Mac ===

Version: 1.11.1.201 (Indie Edition)

=== Build Information ===

Release ID: 507000596
Git revision: d996e9ba6874a0d64241e43e5e6b06322ce29c84
Build date: 2014-11-25 17:17:54-05
Xamarin addins: 8ca19707b41536a391f53364ee4ff9272711feb0

=== Operating System ===

Mac OS X 10.8.4
Darwin Tajinders-iMac.local 12.4.2 Darwin Kernel Version 12.4.2
    Mon Jun 17 18:00:12 PDT 2013
    root:xnu-2050.45.8~1/RELEASE_X86_64 x86_64