Classic API with F#
-[NSDocument writeToURL:ofType:error:] is failing when Xamarin tries to call xamarin_get_nsobject_with_type_for_ptr
This is strange though because my implementation doesn't override that function.
All other document IO functions work in the app (Open, Save), but duplicate is failing.
My document isn't complicated:
type MyDocument =
override this.ReadFromData (data, typeName, outError) = ...
override this.GetAsData (typeName, outError) = ...
I can share the source code with whoever from Xamarin wants to look. https://github.com/praeclarum/Mecha/blob/master/Mecha.Mac/MyDocument.fs
Process: Mecha 
Version: 0.1 (0.1)
Code Type: X86 (Native)
Parent Process: ??? 
Responsible: Mecha 
User ID: 501
Date/Time: 2015-06-08 18:39:01.795 -0700
OS Version: Mac OS X 10.10.3 (14D136)
Report Version: 11
Anonymous UUID: AA5648EF-8537-F153-2CE3-DA8D0C87CAEC
Sleep/Wake UUID: 452F773F-3CE3-4C73-B41C-41839B81371A
Time Awake Since Boot: 170000 seconds
Time Since Wake: 37000 seconds
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000042000000
VM Regions Near 0x42000000:
__LINKEDIT 000000004058b000-00000000406e7000 [ 1392K] r--/rwx SM=COW /System/Library/Extensions/AppleIntelHD5000GraphicsGLDriver.bundle/Contents/MacOS/AppleIntelHD5000GraphicsGLDriver
__TEXT 000000008fe6d000-000000008fe7a000 [ 52K] r-x/rwx SM=COW /usr/lib/dyld
Application Specific Information:
Performing @selector(duplicateDocument:) from sender NSMenuItem 0x9c34760
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x996e269a __pthread_kill + 10
1 libsystem_pthread.dylib 0x95ac3f19 pthread_kill + 101
2 libsystem_c.dylib 0x95933eee abort + 156
3 libmono-2.0.dylib 0x028bf685 mono_handle_native_sigsegv + 757
4 libmono-2.0.dylib 0x0290b3c2 mono_arch_handle_altstack_exception + 162
5 libmono-2.0.dylib 0x0280be5e mono_sigsegv_signal_handler + 446
6 libsystem_platform.dylib 0x90e8203b _sigtramp + 43
7 ??? 0xffffffff 0 + 4294967295
8 libmono-2.0.dylib 0x0280bca0 mono_sigill_signal_handler + 48
9 com.kruegersystems.mecha.mac 0x00009f1e get_raw_gchandle + 46
10 com.kruegersystems.mecha.mac 0x00009eb7 get_gchandle + 23
11 com.kruegersystems.mecha.mac 0x00009c17 xamarin_get_gchandle + 23
12 com.kruegersystems.mecha.mac 0x00009b5e xamarin_get_nsobject_with_type_for_ptr_created + 126
13 com.kruegersystems.mecha.mac 0x00009ad2 xamarin_get_nsobject_with_type_for_ptr + 66
14 com.kruegersystems.mecha.mac 0x0000daee xamarin_trampoline + 2206
15 com.apple.AppKit 0x93559a3d -[NSDocument writeToURL:ofType:error:] + 953
16 com.apple.AppKit 0x9355963e -[NSDocument writeToURL:ofType:forSaveOperation:originalContentsURL:error:] + 509
17 com.apple.AppKit 0x93558c54 -[NSDocument _writeSafelyToURL:ofType:forSaveOperation:forceTemporaryDirectory:error:] + 1051
18 com.apple.AppKit 0x93558820 -[NSDocument _writeSafelyToURL:ofType:forSaveOperation:error:] + 72
19 com.apple.AppKit 0x935583f6 -[NSDocument writeSafelyToURL:ofType:forSaveOperation:error:] + 427
20 com.apple.AppKit 0x936d3776 __38-[NSDocument duplicateAndReturnError:]_block_invoke_2 + 210
21 com.apple.AppKit 0x936ac305 __66-[NSDocument _coordinateReadingContentsAndReturnError:byAccessor:]_block_invoke + 18
22 com.apple.Foundation 0x97b1bede __73-[NSFileCoordinator coordinateReadingItemAtURL:options:error:byAccessor:]_block_invoke_2 + 25
23 com.apple.Foundation 0x97b1bdaf -[NSFileCoordinator _invokeAccessor:thenCompletionHandler:] + 370
24 com.apple.Foundation 0x97b1bc2d __73-[NSFileCoordinator coordinateReadingItemAtURL:options:error:byAccessor:]_block_invoke + 130
25 com.apple.Foundation 0x97d06180 __85-[NSFileCoordinator(NSPrivate) _coordinateReadingItemAtURL:options:error:byAccessor:]_block_invoke388 + 119
26 com.apple.Foundation 0x97b1bb8b -[NSFileCoordinator(NSPrivate) _invokeAccessor:orDont:andRelinquishAccessClaim:] + 348
27 com.apple.Foundation 0x97b1927b -[NSFileCoordinator(NSPrivate) _coordinateReadingItemAtURL:options:error:byAccessor:] + 671
28 com.apple.Foundation 0x97b18fd3 -[NSFileCoordinator coordinateReadingItemAtURL:options:error:byAccessor:] + 138
29 com.apple.AppKit 0x936ac2b7 -[NSDocument _coordinateReadingContentsAndReturnError:byAccessor:] + 221
30 com.apple.AppKit 0x936d369c __38-[NSDocument duplicateAndReturnError:]_block_invoke + 139
31 com.apple.AppKit 0x9350066c __53-[NSDocument performSynchronousFileAccessUsingBlock:]_block_invoke + 20
32 com.apple.AppKit 0x936ab968 __56-[NSDocument _performFileAccessOnMainThread:usingBlock:]_block_invoke705 + 57
33 com.apple.AppKit 0x93347538 -[NSDocument continueFileAccessUsingBlock:] + 258
34 com.apple.AppKit 0x93500523 -[NSDocument _performFileAccessOnMainThread:usingBlock:] + 741
35 com.apple.AppKit 0x93500230 -[NSDocument performSynchronousFileAccessUsingBlock:] + 151
36 com.apple.AppKit 0x936d35f1 -[NSDocument duplicateAndReturnError:] + 172
37 com.apple.AppKit 0x936d2129 __77-[NSDocument duplicateDocumentWithDelegate:didDuplicateSelector:contextInfo:]_block_invoke_2 + 508
38 com.apple.AppKit 0x93508aa4 -[NSDocument _commitEditingThenContinue:] + 526
39 com.apple.AppKit 0x936d1f25 __77-[NSDocument duplicateDocumentWithDelegate:didDuplicateSelector:contextInfo:]_block_invoke + 376
40 com.apple.AppKit 0x933442ba -[NSDocument _processActivity:blockingMainThread:] + 1812
41 com.apple.AppKit 0x93343774 -[NSDocument performActivityWithSynchronousWaiting:usingBlock:cancellationHandler:] + 192
42 com.apple.AppKit 0x9350720f -[NSDocument performActivityWithSynchronousWaiting:usingBlock:] + 56
43 com.apple.AppKit 0x936d1da5 -[NSDocument duplicateDocumentWithDelegate:didDuplicateSelector:contextInfo:] + 137
44 com.apple.AppKit 0x936d1d17 -[NSDocument duplicateDocument:] + 57
45 libobjc.A.dylib 0x9ba9f853 -[NSObject performSelector:withObject:] + 70
46 com.apple.AppKit 0x933817ee __36-[NSApplication sendAction:to:from:]_block_invoke + 51
47 libsystem_trace.dylib 0x9c1e9c03 _os_activity_initiate + 89
48 com.apple.AppKit 0x93381707 -[NSApplication sendAction:to:from:] + 602
49 com.apple.AppKit 0x933813ad -[NSMenuItem _corePerformAction] + 479
50 com.apple.AppKit 0x9338109e -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 162
51 com.apple.AppKit 0x9338071a -[NSMenu _performActionWithHighlightingForItemAtIndex:sendAccessibilityNotification:] + 79
52 com.apple.AppKit 0x933806c2 -[NSMenu _performActionWithHighlightingForItemAtIndex:] + 48
53 com.apple.AppKit 0x9338067f __31-[NSMenu performKeyEquivalent:]_block_invoke + 43
54 libsystem_trace.dylib 0x9c1e9c03 _os_activity_initiate + 89
55 com.apple.AppKit 0x9337fec3 -[NSMenu performKeyEquivalent:] + 380
56 com.apple.AppKit 0x9337eebb -[NSApplication _handleKeyEquivalent:] + 918
57 com.apple.AppKit 0x9327c4dc -[NSApplication sendEvent:] + 4581
58 com.apple.AppKit 0x9319c7dc -[NSApplication run] + 1003
59 com.apple.AppKit 0x93111bc0 NSApplicationMain + 2082
60 ??? 0x06f45264 0 + 116675172
61 ??? 0x06f45070 0 + 116674672
62 ??? 0x007bb0d4 0 + 8106196
63 ??? 0x007bb27c 0 + 8106620
64 libmono-2.0.dylib 0x0280e90f mono_jit_runtime_invoke + 751
65 libmono-2.0.dylib 0x029d0b0f mono_runtime_invoke + 127
66 libmono-2.0.dylib 0x029d6b81 mono_runtime_exec_main + 401
67 libmono-2.0.dylib 0x029d6944 mono_runtime_run_main + 628
68 libmono-2.0.dylib 0x0288932d mono_jit_exec + 93
69 libmono-2.0.dylib 0x0288b600 mono_main + 7904
70 com.kruegersystems.mecha.mac 0x0000609d mono_main_impl + 45
71 com.kruegersystems.mecha.mac 0x0001e704 main + 852
72 com.kruegersystems.mecha.mac 0x00002235 start + 53
at <unknown> <0xffffffff>
at (wrapper managed-to-native) MonoMac.AppKit.NSApplication.NSApplicationMain (int,string) <IL 0x000ac, 0xffffffff>
at MonoMac.AppKit.NSApplication.Main (string) [0x00041] in /Users/builder/data/lanes/1503/e6ebd18b/source/maccore/src/AppKit/NSApplication.cs:94
at Mecha.Mac.main.main (string) [0x00006] in /Users/fak/Dropbox/Projects/Mecha/Mecha.Mac/AppDelegate.fs:22
at (wrapper runtime-invoke) <Module>.runtime_invoke_int_object (object,intptr,intptr,intptr) <IL 0x0006c, 0xffffffff>
Debug info from gdb:
(lldb) command source -s 1 '/tmp/mono-gdb-commands.mKFIy2'
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
Process 48275 detached
=== Xamarin Studio ===
Version 5.9.3 (build 1)
Installation UUID: fce13fdd-e8e3-48ef-99f1-4acbb06f0240
Mono 4.0.1 ((detached/ed1d3ec)
GTK+ 2.24.23 (Raleigh theme)
Package version: 400010044
=== Apple Developer Tools ===
Xcode 6.3.2 (7718)
=== Xamarin.iOS ===
Version: 220.127.116.11 (Enterprise Edition)
Build date: 2015-05-21 21:55:09-0400
=== Xamarin.Android ===
Version: 18.104.22.168 (Enterprise Edition)
Android SDK: /Users/fak/Library/Developer/Xamarin/android-sdk-mac_x86
Supported Android versions:
2.3 (API level 10)
4.0.3 (API level 15)
4.3 (API level 18)
4.4 (API level 19)
5.0 (API level 21)
Java SDK: /usr
java version "1.8.0_20-ea"
Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b23)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b22, mixed mode)
=== Xamarin Android Player ===
Version: Unknown version
Location: /Applications/Xamarin Android Player.app
=== Xamarin.Mac ===
Version: 22.214.171.124 (Enterprise Edition)
=== Build Information ===
Release ID: 509030001
Git revision: 5a524e1726ed103fdd4fe37e0356f2b35466ce9d
Build date: 2015-06-02 16:35:08-04
Xamarin addins: 51957cfbd06be911b212671ad05c2c6221ac90f9
=== Operating System ===
Mac OS X 10.10.3
Darwin muon.local 14.3.0 Darwin Kernel Version 14.3.0
Mon Mar 23 11:59:05 PDT 2015
I have tried to reproduce this issue with the help provided in bug description, but not able to reproduce this. I go through the link for code provided in the bug description but that is broken.
Could you please share steps to reproduce this issue or a small sample application that demonstrate this issue. That would be very helpful to reproduce this issue efficiently at our end.
The link is not broken, you don't have access. If an engineer requests access I will grant it.
I'm sorry you weren't able to reproduce. Try harder.
xamarin_get_nsobject_with_type_for_ptr makes it sound like we're trying to surface a C# type for something that isn't there or deallocated?
Frank - it would be very useful for us to get a sample that reproduces the issue. That's what Rajneesh is looking for. Does this only show up in F#? I can take a look at your code, but a small example project would be even more awesome.
And by C# type, I mean managed type.
Very helpful or required? Given that you keep closing this bug I guess it's required.
You've looked at this code base before and used it to fix bugs before.
It's frustrating that I can't just post a bug and trust that you'll fix it. Shall I debug the runtime too? Find the errant line of code and patch it?
whats this insistence on fresh code? A crash is a crash. Whether 10 lines produced it or 10,000.
Frank - I don't know of anyone who has closed a bug? NEED INFO != Closed. I stuck it in that state to note "hey, I'm expecting to hear back from the reporter before considering this ready to work on. Since you offered in #0 to share the source code, it seemed reasonable.
Sorry for the frustration you are obviously feeling. Before responding, I poked around a bit with F# and realized I don't know enough to reproduce your issue there. I tried a bit in C# and was unable to run into your specific issue.
I can, and will, at some point try to go from your stack trace into an example that reproduces the issue. Having an example showing the problem makes turning around bugs take an order of magnitude less time.
If there is anything else I can do for you, feel free to mail of off thread.
Need Info means you're not working on it...
Anyway, I wrote you a minimal repro. I am curious how it differs from Rajneesh's:
2. Save the doc
3. Duplicate the doc
Result: exact same stack trace as I showed before.
It's just a template document-based app (a template that used to be included with Xamarin.Mac).
No logic doing anything interesting. That's why I thought you'd be able to repro it yourselves.
@Frank - Not a lot of us have F# experience, so reproducing bugs in F# that don't reproduce in C# is a tall order.
So, I'm thinking this has to be a c# specific bug.
I created a C# program and tried to simply your example and move them closer and closer together. However, the C# version still works and the F# one does not.
I've attached them both.
I can confirm that something is going on, and that we'll have to look into it further.
Created attachment 11538 [details]
Created attachment 11539 [details]
I'm going to get our F# guy to look and see where my C# version differs from F#. It could be a bug that's F# specific, but I still have hope that poking the C# the right way will expose the bug there.
@Frank - There is something wrong going on here that is deeper than first glance. We'll get back to you when we do some more digging.
This is OS X being nasty :( They call your override, but for the "out NSError" parameter they provide a pointer to garbage (instead of a pointer to nil), which means that when we try to convert the pointer to an NSError, we access garbage instead.
This is not a problem for C#, because there we check the signature and find out that the parameter is 'out' (and we only write to it, we don't read to it), but for F# there's no ref/out distinction, so we read it as well.
The fix would probably be to look for the parameters in the base signature (in this case NSDocument.GetAsData) to see if it's a ref or out parameter. I'll try to implement this.
This also means there's a fairly easy workaround, just apply the corresponding attribute to the parameter:
> override this.GetAsData (typeName, [<System.Runtime.InteropServices.OutAttribute>] outError) =
*** Bug 34509 has been marked as a duplicate of this bug. ***
I just ran into this as well. I understand there is a workaround, but it's ugly for our users to have to come find this bug in bugzilla to know that we don't handle out params right.
I have checked this issue with the following build from cycle 7:
To test this issue I have used the F# sample provided in the comment 9 and I am successfully able to build and run it successfully. I also created the duplicate of document and able to create successfully.
This issue has been fixed, hence I am closing this issue.