Bug 42584 - InternalError / Crash when using System.Net.Http and PCL library
Summary: InternalError / Crash when using System.Net.Http and PCL library
Alias: None
Product: Runtime
Classification: Mono
Component: Reflection ()
Version: master
Hardware: PC Mac OS
: Normal normal
Target Milestone: 4.8.0 (C9)
Assignee: Aleksey Kliger
: 39047 43449 ()
Depends on:
Reported: 2016-07-15 09:13 UTC by Johannes Rudolph
Modified: 2016-12-02 18:49 UTC (History)
13 users (show)

Tags: potentialC8SR2
Is this bug a regression?: Yes
Last known good build: cycle6

Repro Solution Project (147.15 KB, application/zip)
2016-07-15 09:13 UTC, Johannes Rudolph

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 GitHub or Developer Community 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 Johannes Rudolph 2016-07-15 09:13:00 UTC
Created attachment 16677 [details]
Repro Solution Project

The attached repro project fails running unit-tests with a non-descript "Internal error" in the test results pane. Using Xamarin Cycle 6 latest stable with this same project does work as it should (test passes). 

Workaround: Apparently this can be worked around by setting the NunitRepro project's reference to System.Net.Http.dll to _not_ " Local Copy" and adding an app.config to NunitRepro project with the following content: 

<?xml version="1.0" encoding="utf-8"?>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <assemblyIdentity name="System.Net.Http.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="" newVersion="" />
        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="" newVersion="" />

I consider this bug a regression from Release Cycle 6, likely an issue in Mono or in the build engine to do with assembly loading / reference resolution.

Environment used to test:
Xamarin Studio Business
Version 6.0.1 (build 9)
Installation UUID: 3cbf1b60-0560-4942-8de5-aedf17c5251e
	Mono 4.4.1 (mono-4.4.0-branch-c7sr0/4747417) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 404010000
Comment 1 Lluis Sanchez 2016-07-15 13:26:09 UTC
The runtime is crashing: https://gist.github.com/slluis/d218dddb0bba878e8d2f6384afc80cae
Comment 2 Rodrigo Kumpera 2016-07-20 01:21:36 UTC
The crash was fixed in mono 4.6.0.

The issue in this case is that result of the build process includes an invalid assembly with no IL.

Marek, could this be the current issue we're experiencing?
Comment 3 Rodrigo Kumpera 2016-07-20 17:53:09 UTC
Alexander, can you work out if it's netstandard?
Comment 4 Marek Safar 2016-07-27 09:58:08 UTC
This has nothing to do with netstandard. Import part is XS step

Copying file from '/Users/xxx/mono/lib/mono/4.5-api/System.Net.Http.dll' to '/Users/xxx/Downloads/NunitRepro/bin/Debug/System.Net.Http.dll'

which is wrong as 4.5-api is only api dll so XS (or xbuild) has to translate this path when user check 'Local Copy' on assembly reference
Comment 5 Alexander Köplinger [MSFT] 2016-07-27 10:27:25 UTC
fwiw VS doesn't translate the path either, it simply copies the reference assembly as well. It seems to work on .NET because there the GAC wins first when loading an assembly.

A feature in the runtime like https://bugzilla.xamarin.com/show_bug.cgi?id=39047 to prevent loading of ref asms would make this easier to diagnose.
Comment 6 Lluis Sanchez 2016-07-27 10:46:25 UTC
In any case, it is not an XS issue. XS does not copy the assemblies.
Comment 7 Marek Safar 2016-08-17 12:30:25 UTC
This is due to runtime not recognising special ReferenceAssemblyAttribute

With sample like

// compile with -t:lib x-lib

using System.Runtime.CompilerServices;

[assembly: ReferenceAssemblyAttribute]

public class XX

// compile with -r:x-lib.dll

public class MM
	public static void Main ()
		new XX ();

.NET throws

Unhandled Exception: System.BadImageFormatException: Could not load file or assembly 'x-lib, Version=, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Reference assemblies should not be loaded for execution.  They can only be loaded in the Reflection-only loader context. (Exception from HRESULT: 0x80131058) ---> System.BadImageFormatException: Cannot load a reference assembly for execution.
   --- End of inner exception stack trace ---
   at MM.Main()

Mono loads the assembly.

Note: This is just simple example. The intended behaviour is to skip ReferenceAssembly whenever they appear in execution loading binder.
Comment 8 Marek Safar 2016-08-24 08:50:16 UTC
*** Bug 39047 has been marked as a duplicate of this bug. ***
Comment 9 Aleksey Kliger 2016-09-02 15:00:23 UTC
Fixed on mono master with commit c8287cd329b33b18309ca038c1b7b4be957faf39
Fixed on mono mono-4.6.0-branch with commit bdce6068d50f0db1a69687cc883bf1bf519f25fa
Comment 11 Luis Aguilera 2016-09-12 20:14:19 UTC
since C8 is now closed, and is shipping this week, I will move this but to the C8SR1 milestone. We'll continue working on the issue seeking it's resolution as soon as possible.
Comment 12 Marek Safar 2016-10-06 16:07:41 UTC
*** Bug 43449 has been marked as a duplicate of this bug. ***
Comment 14 Aleksey Kliger 2016-10-31 20:29:54 UTC
Hit a deadlock in mono_assembly_load_reference ().  Needs some followup work.
Comment 15 Aleksey Kliger 2016-11-02 18:57:00 UTC
Follow up work to get rid of deadlock issue from Comment 14

mono master

mono mono-4.8.0-branch
Comment 16 Aleksey Kliger 2016-11-07 14:45:55 UTC
Haven't seen any  more issues since Comment 15.  I'm gonna say this one is finally done.