Xamarin-macios: Strong name and InternalsVisibleTo crash on device (works on emulator)

Created on 30 Sep 2018 · 5Comments · Source: xamarin/xamarin-macios

This issue happens when using the Sentry SDK with Xamarin.iOS. All the assemblies that comprise that SDK are strong named and the Protocol package exposes internals to the Sentry package.

I've created a small reproducible app.

Steps to Reproduce

Checkout the repro: https://github.com/bruno-garcia/repro-xamarin-ios-strong-name-internalsvisibleto
Run the app in any device (tested on ipod with iOS 11.4.1)

It works with the iOS emulators and with Android devices.

Expected Behavior

App starts

Actual Behavior

App crashes

Environment

=== Visual Studio Community 2017 for Mac (Preview) ===

Version 7.7 Preview (7.7 build 1282)
Installation UUID: 7a7b3772-1996-435b-8eda-9b208ec21ddd
Runtime:
    Mono 5.16.0.151 (2018-06/5e81afa90df) (64-bit)
    GTK+ 2.24.23 (Raleigh theme)
    Xamarin.Mac 4.4.1.178 (master / eeaeb7e6)

    Package version: 516000151

=== NuGet ===

Version: 4.3.1.4445

=== .NET Core ===

Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
    2.1.2
    2.1.1
    2.1.0-rc1
    2.0.6
    2.0.5
    1.1.7
    1.0.10
SDK: /usr/local/share/dotnet/sdk/2.1.400/Sdks
SDK Versions:
    2.1.400
    2.1.302
    2.1.301
    2.1.300-rc1-008673
    2.1.101
    2.1.4
    1.1.8
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/5.16.0/lib/mono/msbuild/15.0/bin/Sdks

=== Xamarin.Profiler ===

Version: 1.6.4
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Apple Developer Tools ===

Xcode 10.0 (14320.25)
Build 10A255

=== Xamarin.Mac ===

Version: 4.8.0.22 (Visual Studio Community)
Hash: bd81f1c3
Branch: 
Build date: 2018-08-24 17:10:45-0400

=== Xamarin.iOS ===

Version: 11.16.0.22 (Visual Studio Community)
Hash: bd81f1c3
Branch: HEAD
Build date: 2018-08-24 17:10:45-0400

=== Xamarin.Android ===

Version: 9.1.0.17 (Visual Studio Community)
Android SDK: /Users/bruno/Library/Developer/Xamarin/android-sdk-macosx
    Supported Android versions:
        7.1 (API level 25)
        8.1 (API level 27)

SDK Tools Version: 26.1.1
SDK Platform Tools Version: 26.0.2
SDK Build Tools Version: 26.0.3

Java SDK: /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

=== Android Device Manager ===

Version: 7.7.1.0
Hash: f11c178f

=== Xamarin Inspector ===

Version: 1.4.3
Hash: db27525
Branch: 1.4-release
Build date: Mon, 09 Jul 2018 21:20:18 GMT
Client compatibility: 1

=== Build Information ===

Release ID: 707001282
Git revision: cfff48c7cf9ee2db7ccad51846abf697c0bc2b91
Build date: 2018-09-07 18:06:37+00
Build branch: release-7.7
Xamarin extensions: ce83fabc2c8823a41b3981363c8ee39bdde61612

=== Operating System ===

Mac OS X 10.13.6
Darwin 17.7.0 Darwin Kernel Version 17.7.0
    Thu Jun 21 22:53:14 PDT 2018
    root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64

=== Enabled user installed extensions ===

Internet of Things (IoT) development (Preview) 7.5

Build Logs

App builds and deploys to the device, the crash is:

Unhandled Exception:
System.MethodAccessException: Method `Bla.DoNothing()' is inaccessible from method `Ble.DontThrow()'
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_throw_method_access(intptr,intptr)
  at InternalsVisibleStrongNamed.Application.Main (System.String[] args) <0x100abb070 + 0x00023> in <e9f72ebbc6ca4ed589535b6cc146eceb#72fb15896f6c5cfbdf855a3eee9de4dc>:0 
2018-09-30 14:23:45.302 InternalsVisibleStrongNamed[387:147683] Unhandled managed exception:
Method `Bla.DoNothing()' is inaccessible from method `Ble.DontThrow()' (System.MethodAccessException)
  at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_throw_method_access(intptr,intptr)
  at InternalsVisibleStrongNamed.Application.Main (System.String[] args) <0x100abb070 + 0x00023> in <e9f72ebbc6ca4ed589535b6cc146eceb#72fb15896f6c5cfbdf855a3eee9de4dc>:0 
2018-09-30 14:23:45.302 InternalsVisibleStrongNamed[387:147683] critical: Stacktrace:

2018-09-30 14:23:45.302 InternalsVisibleStrongNamed[387:147683] critical: 
Native stacktrace:

2018-09-30 14:23:45.303 InternalsVisibleStrongNamed[387:147683] critical:   0   InternalsVisibleStrongNamed         0x0000000100c7c74c InternalsVisibleStrongNamed + 1869644
2018-09-30 14:23:45.303 InternalsVisibleStrongNamed[387:147683] critical:   1   libsystem_platform.dylib            0x0000000181eb8b58 _sigtramp + 52
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   2   libsystem_pthread.dylib             0x0000000181ebe288 <redacted> + 376
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   3   libsystem_c.dylib                   0x0000000181c8bd0c abort + 140
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   4   InternalsVisibleStrongNamed         0x0000000100d82bf0 xamarin_get_block_descriptor + 4448
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   5   InternalsVisibleStrongNamed         0x0000000100cb90c0 InternalsVisibleStrongNamed + 2117824
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   6   InternalsVisibleStrongNamed         0x0000000100c7c398 InternalsVisibleStrongNamed + 1868696
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   7   InternalsVisibleStrongNamed         0x0000000100c7b0e8 InternalsVisibleStrongNamed + 1863912
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   8   InternalsVisibleStrongNamed         0x0000000100c73314 InternalsVisibleStrongNamed + 1831700
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   9   InternalsVisibleStrongNamed         0x0000000100b0c308 InternalsVisibleStrongNamed + 361224
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   10  InternalsVisibleStrongNamed         0x0000000100af9198 InternalsVisibleStrongNamed + 283032
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   11  InternalsVisibleStrongNamed         0x0000000100abb094 InternalsVisibleStrongNamed + 28820
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   12  InternalsVisibleStrongNamed         0x0000000100af85a8 InternalsVisibleStrongNamed + 279976
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   13  InternalsVisibleStrongNamed         0x0000000100c8ba10 InternalsVisibleStrongNamed + 1931792
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   14  InternalsVisibleStrongNamed         0x0000000100cf2094 InternalsVisibleStrongNamed + 2351252
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   15  InternalsVisibleStrongNamed         0x0000000100cf7338 InternalsVisibleStrongNamed + 2372408
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   16  InternalsVisibleStrongNamed         0x0000000100c72b28 InternalsVisibleStrongNamed + 1829672
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   17  InternalsVisibleStrongNamed         0x0000000100d88cfc xamarin_find_protocol_wrapper_type + 24688
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   18  InternalsVisibleStrongNamed         0x0000000100abaf38 InternalsVisibleStrongNamed + 28472
2018-09-30 14:23:45.304 InternalsVisibleStrongNamed[387:147683] critical:   19  libdyld.dylib                       0x0000000181bedfc0 <redacted> + 4
2018-09-30 14:23:45.305 InternalsVisibleStrongNamed[387:147683] critical: 
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

Application 'Test.InternalsVisibleStrongNamed' terminated.

Example Project (If Possible)

https://github.com/bruno-garcia/repro-xamarin-ios-strong-name-internalsvisibleto

Branch work/removed-strong-naming had the strong name removed and the app starts normally.

bug iOS

Source

bruno-garcia

Most helpful comment

Workaround: Put a space before PublicKey=, e.g.

[assembly: InternalsVisibleTo ("Lib.B, PublicKey=002...

instead of

[assembly: InternalsVisibleTo ("Lib.B,PublicKey=002...

Unlike most other assembly data being processed this value is a string, and not pre-parsed, metadata reference. As such the formatting is not guaranteed.

This also explains why this is working in so many other cases (and tests that we have).

spouliot on 2 Oct 2018

👍2

All 5 comments

Hi,

I was able to confirm the issue with the attached test case. Could be a signing issue.

Full build logs: https://gist.github.com/VincentDondain/6d6ae0a19baf12c6b4c600c5bc84928a

VincentDondain on 1 Oct 2018

@VincentDondain Thanks for taking a look.

As we can't rely on a fix from your end to unlock our users, I've worked around it (luckily, since the Future label scares me :)) by removing any dependency to internals and removing the InternalsVisibleTo.

That means this issue is no longer blocking us.

bruno-garcia on 1 Oct 2018

It's not related to simulator or device builds. Enabling the linker on simulator builds trigger the same runtime exception.

That's likely because of .netstandard which force us to update the references (and not ship all facades) in assemblies - which would break the signature. However mono did not, historically, check signatures at runtime.

@luhenry has mono changed its runtime checks wrt [InternalsVisibleTo] recently (that's 2018-04) ?

spouliot on 2 Oct 2018

hmm... maybe not (mono)

[assembly: InternalsVisibleTo ("Lib.B,PublicKey=002400000480000094000000060200000024000052534131000400000100010059964a931488bcdbd14657f1ee0df32df61b57b3d14d7290c262c2cc9ddaad6ec984044f761f778e1823049d2cb996a4f58c8ea5b46c37891414cb34b4036b1c178d7b582289d2eef3c0f1e9b692c229a306831ee3d371d9e883f0eb0f74aeac6c6ab8c85fd1ec04b267e15a31532c4b4e2191f5980459db4dce0081f1050fb8")] is not present, after linking.

spouliot on 2 Oct 2018

Workaround: Put a space before PublicKey=, e.g.

[assembly: InternalsVisibleTo ("Lib.B, PublicKey=002...

instead of

[assembly: InternalsVisibleTo ("Lib.B,PublicKey=002...

Unlike most other assembly data being processed this value is a string, and not pre-parsed, metadata reference. As such the formatting is not guaranteed.

This also explains why this is working in so many other cases (and tests that we have).

spouliot on 2 Oct 2018

👍2

Was this page helpful?

0 / 5 - 0 ratings