Forum Xamarin.iOS

Native crash with Xamarin.Mac 2.8 using binding library (created with bmac)

CsabaBalintCsabaBalint USMember
edited July 2016 in Xamarin.iOS

Hello,

Our company has a Xamarin.Mac application which uses the Classic API. Currently we're using the following components with Mac OS X 10.11.6

=== Xamarin Studio Enterprise ===

Version 5.10.3 (build 51)
Installation UUID: f34adbd6-1479-46c4-84fb-ee0d1d8e6bde
Runtime:
    Mono 4.2.3 (explicit/832de4b)
    GTK+ 2.24.23 (Raleigh theme)

    Package version: 402030004

=== Xamarin.Mac ===

Version: 2.4.2.1 (Xamarin Enterprise)

We plan to update to the latest stable versions and I made a try to check if the application is still working built with Xamarin Studio 6 and Xamarin.Mac 2.8. I have also updated Mono to 4.4.1.

After the update our solution was loaded and compiled successfully and basically it was running fine, but we have a library that is a binding library to the native ImageCaptureCore framework that was created with bmac which is not working correctly. At a given point a callback from the ImageCaptureCore causes an application crash:

Exception Type:        EXC_BAD_ACCESS (SIGABRT)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000069727453
Exception Note:        EXC_CORPSE_NOTIFY

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          0x9c96f572 __pthread_kill + 10
1   libsystem_pthread.dylib         0x97e03654 pthread_kill + 101
2   libsystem_c.dylib               0x9b6ecc38 abort + 156
3   com.Canon.iristaUploader        0x001b12a5 mono_handle_native_sigsegv + 757
4   com.Canon.iristaUploader        0x00142a62 mono_arch_handle_altstack_exception + 162 (exceptions-x86.c:1097)
5   com.Canon.iristaUploader        0x001bc07e mono_sigsegv_signal_handler + 446 (mini-runtime.c:2489)
6   libsystem_platform.dylib        0x91fb879b _sigtramp + 43
7   ???                             0xffffffff 0 + 4294967295
8   com.Canon.iristaUploader        0x001bbec0 mono_sigill_signal_handler + 48 (mini-runtime.c:2398)
9   com.apple.ImageCaptureCore      0x97f53380 -[ICMasterDeviceBrowser handleCommandCompletion:] + 580
10  libobjc.A.dylib                 0x95a7e3ee -[NSObject performSelector:withObject:] + 70
11  com.apple.ImageCaptureCore      0x97f19bc7 -[ICCommandCenter handleCompletionEvent:replyEvent:] + 460
12  com.apple.ImageCaptureCore      0x97f1ac82 -[ICCommandCenter handleMachMessage:] + 431
13  com.apple.Foundation            0x9c17c156 __NSFireMachPort + 417
14  com.apple.CoreFoundation        0x909c72da __CFMachPortPerform + 330
15  com.apple.CoreFoundation        0x909c7185 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 53
16  com.apple.CoreFoundation        0x909c70f0 __CFRunLoopDoSource1 + 512
17  com.apple.CoreFoundation        0x909be639 __CFRunLoopRun + 2649
18  com.apple.CoreFoundation        0x909bd976 CFRunLoopRunSpecific + 390
19  com.apple.CoreFoundation        0x909bd7db CFRunLoopRunInMode + 123
20  com.apple.HIToolbox             0x9b2db2f1 RunCurrentEventLoopInMode + 267
21  com.apple.HIToolbox             0x9b2db0f3 ReceiveNextEventCommon + 503
22  com.apple.HIToolbox             0x9b2daeec _BlockUntilNextEventMatchingListInModeWithFilter + 99
23  com.apple.AppKit                0x922382e2 _DPSNextEvent + 1053
24  com.apple.AppKit                0x9223785b -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1057
25  com.apple.AppKit                0x92237432 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 121
26  com.apple.AppKit                0x9222ab47 -[NSApplication run] + 1063
27  com.apple.AppKit                0x921f1469 NSApplicationMain + 1630
28  ???                             0x04bf1f54 0 + 79634260
29  ???                             0x04bf1d30 0 + 79633712
30  ???                             0x00d881bc 0 + 14188988
31  ???                             0x00d88338 0 + 14189368
32  com.Canon.iristaUploader        0x001beeea mono_jit_runtime_invoke + 714 (mini-runtime.c:2345)
33  com.Canon.iristaUploader        0x0028548f mono_runtime_invoke + 127 (object.c:2783)
34  com.Canon.iristaUploader        0x0028b131 mono_runtime_exec_main + 401 (object.c:4038)
35  com.Canon.iristaUploader        0x0028aeea mono_runtime_run_main + 618 (object.c:3666)
36  com.Canon.iristaUploader        0x001397ed mono_jit_exec + 93 (driver.c:1007)
37  com.Canon.iristaUploader        0x0013bb41 mono_main + 7985 (driver.c:2080)
38  com.Canon.iristaUploader        0x000e07be main + 798 (launcher.m:551)
39  libdyld.dylib                   0x9bf7e6ad start + 1

The first question is, can we use the Classic API in the future along with the latest Xamarin.Mac version (and Xamarin Studio)?
If the answer is yes (I suppose), can you help us to find what is causing the crash?

Let me know if any further detail needed.

Thanks
Peter Zsikai

Best Answer

Answers

  • CsabaBalintCsabaBalint USMember

    Thank you Chris!

    After the update and when the crash happened, I was tempted to try to migrate our projects to the Unified API hoping it will help to solve this, unfortunately I was facing some difficulties, will ask about it below.

    Still, when I read the release notes and sections about the Unified API, I noticed a lot of improvements, so I never wanted to stick to the Classic API, but the fact that the application (and the bounded ImageCaptureCore framework) built with our current environment - mentioned above - works, forces us to stay on classic, at least for now.

    So, when I was migrating our projects, I decided to do the manual way. Updating the projects, removing MonoMac namespace and replacing .Net classes with CoreGraphics classes was done, then I gave up when I found that several constants in NSAttributedString were removed from Unified API, e.g.

    public static NSString ParagraphStyleAttributeName { get; }
    

    and I didn't find these strings anywhere else. Probably I missed something, and these constants can be found somewhere in the Unified API?

    I'll be on holiday in the next weeks, then I come back and will take the time again to perform the migration.

  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai

    That was one of the more disruptive changes unfortunately, but an easy fix. Take a look at NSStringAttributeKey.ParagraphStyle though, we just renamed to match the existing patterns.

    One tip if you really can't find something, go checkout our source code (https://github.com/xamarin/xamarin-macios/tree/master/src) and grep through it for the selector you are looking for. Often that'll point you to the right class.

    In theory our documentation should be awesome enough to never need to do that, but we're not there yet (though documentation is getting more awesome every release!).

  • I have successfully migrated all the projects using Classic API to Unified API. It could have been easier if we wouldn't use the mentioned framework (ImageCaptureCore) but we do :)

    Now everything is working as expected based on our tests. We use now the latest version of both Xamarin Studio (6.1) and Xamarin.Mac (2.10) during development.

  • ChrisHamonsChrisHamons USForum Administrator, Xamarin Team Xamurai

    \o/

Sign In or Register to comment.