Bug 18368 - Compiler crashed when using custom runtime
Summary: Compiler crashed when using custom runtime
Status: RESOLVED DUPLICATE of bug 17820
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Project Model ()
Version: 5.0
Hardware: PC Mac OS
: Normal normal
Target Milestone: 5.0
Assignee: Lluis Sanchez
Depends on:
Reported: 2014-03-13 15:59 UTC by Martin Baulig
Modified: 2014-03-19 09:27 UTC (History)
3 users (show)

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

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:

Description Martin Baulig 2014-03-13 15:59:53 UTC
This is a very weird error, I'm getting this error message:

Building Solution: SimpleTest (Debug|x86)

Building: SimpleTest (Debug|x86)

Build started 3/13/2014 8:50:48 PM.
Project "/Users/martin/Projects/SimpleTest/SimpleTest/SimpleTest.csproj" (Build target(s)):
	Target PrepareForBuild:
		Configuration: Debug Platform: x86
	Target GenerateSatelliteAssemblies:
	No input files were specified for target GenerateSatelliteAssemblies, skipping.
	Target CoreCompile:
		Tool /Workspace/INSTALL/lib/mono/4.5/mcs.exe execution started with arguments: /noconfig /debug:full /debug+ /optimize- /out:obj/x86/Debug/SimpleTest.exe Program.cs Properties/AssemblyInfo.cs obj/x86/Debug/.NETFramework,Version=v4.0.AssemblyAttribute.cs /target:exe /define:DEBUG /nostdlib /platform:x86 /reference:/Workspace/INSTALL/lib/mono/4.0/System.dll /reference:/Workspace/INSTALL/lib/mono/4.0/System.Core.dll /reference:/Workspace/INSTALL/lib/mono/4.0/mscorlib.dll /warn:4
/Workspace/INSTALL/lib/mono/4.5/Microsoft.CSharp.targets: error : Compiler crashed with code: 255.
	Task "Csc" execution -- FAILED
	Done building target "CoreCompile" in project "/Users/martin/Projects/SimpleTest/SimpleTest/SimpleTest.csproj".-- FAILED
Done building project "/Users/martin/Projects/SimpleTest/SimpleTest/SimpleTest.csproj".-- FAILED


/Users/martin/Projects/SimpleTest/SimpleTest/SimpleTest.csproj (Build) ->
/Workspace/INSTALL/lib/mono/4.5/Microsoft.CSharp.targets (CoreCompile target) ->

	/Workspace/INSTALL/lib/mono/4.5/Microsoft.CSharp.targets: error : Compiler crashed with code: 255.

	 0 Warning(s)
	 1 Error(s)

Time Elapsed 00:00:00.1588940

---------------------- Done ----------------------

Build: 1 error, 0 warnings

I am using Xamarin Studio 5.0 (build 268) using the wrench build of commit 10a78b6.

The problem only happens when using a custom Mono runtime.  To ensure that there are no compatibility problems, I use the exact same commit for both.

I quit Xamarin Studio, then built mono/master commit 93fe81b and installed it in /Workspace/INSTALL.  Then downloaded the wrench build of that revision and installed it.  Now both runtimes should have the exact same binaries as they were build from the same commit.

Now I start Xamarin Studio, check ".NET Runtimes" in the Preferences, the newly installed "Mono 3.4.0" is the default and "Mono 3.4.0 ((detached/93fe81b)(/Workspace/INSTALL)" the second one (btw. just realized there's a cosmetic bug: there should be another closing parenthesis).

Create a simple C# Console App, build it - no problem.  Build again, no problem.

Then go to Project / Active Runtime and switch to the /Workspace/INSTALL one, Build All and I get "Compiler crashed with error code 255."

This problem is really new, I've always used multiple runtimes without any problems.  I saw it the first time after upgrading Xamarin Studio this morning, using my custom-built runtime that was previously working find.  To eliminate any possible compatibility problems, I then rebuilt Mono using that specific revision.
Comment 1 Martin Baulig 2014-03-13 16:00:59 UTC
Btw. invoking that full mcs command on the command-line works perfectly fine - using both runtimes.  The command-line xbuild also builds the solution without any problems.
Comment 2 Martin Baulig 2014-03-16 22:05:52 UTC
The most annoying thing about this is that even downgrading to older versions of Xamarin Studio does not make this go away.

I'll try to debug this and find the problem.
Comment 3 Martin Baulig 2014-03-17 00:19:17 UTC
I have tracked this down until the Microsoft.Build.Utilities.ToolTask.ExecuteTool().

We launch "/Workspace/INSTALL/lib/mono/4.5/mcs.exe" with correct arguments - the same call works fine from the command line.  The process does not produce any output, setting shell execute on/off has no effect.

The strange thing is that if I chance the process name to "/usr/bin/mono" and add the "mcs.exe" to the command-line args, then it works.  I tried to do the same with a stand-alone console app, but failed to reproduce this.

Simplest way of triggering this error:

Create a new C# Console Application (mine is ~/Projects/SimpleTest), then invoke:

$ /usr/bin/mono --debug /Applications/Xamarin\ Studio.app/Contents/MacOS/lib/monodevelop/bin/mdtool.exe build -r:/Workspace/INSTALL ~/Projects/SimpleTest/SimpleTest.sln 

This invokes

Tool /Workspace/INSTALL/lib/mono/4.5/mcs.exe execution started with arguments: /noconfig /debug:full /debug+ /optimize-
      /out:obj/x86/Debug/SimpleTest.exe Program.cs Properties/AssemblyInfo.cs /target:exe /define:DEBUG /nostdlib /platform:x86
      /reference:/Workspace/INSTALL/lib/mono/4.0/System.dll /reference:/Workspace/INSTALL/lib/mono/4.0/System.Core.dll
      /reference:/Workspace/INSTALL/lib/mono/4.0/mscorlib.dll /warn:4

Remove the '-r:/Workspace/INSTALL' and it invokes

      		Tool /Library/Frameworks/Mono.framework/Versions/3.2.5/bin/dmcs execution started with arguments: /noconfig /debug:full /debug+ /optimize- /out:obj/x86/Debug/SimpleTest.exe Program.cs Properties/AssemblyInfo.cs /target:exe /define:DEBUG /platform:x86
      /reference:/Library/Frameworks/Mono.framework/Versions/3.2.5/lib/mono/4.0/System.Core.dll /warn:4

Note that this invokes the 'dmcs' shell script and now the 'mcs.exe' assembly.

The problem also goes away when I replace "/Workspace/INSTALL/lib/mono/4.5/mcs.exe" with "/Workspace/INSTALL/bin/mcs".

So I suggest we chance whatever code in XS is calling that to use the 'mcs' shell-script instead of the mcs assembly.
Comment 4 Martin Baulig 2014-03-17 00:25:08 UTC
This is not related to "mcs.exe" - the same thing happens when attempting to execute any .NET Assembly there.
Comment 5 Marek Safar 2014-03-17 04:17:05 UTC

*** This bug has been marked as a duplicate of bug 17820 ***
Comment 6 Martin Baulig 2014-03-17 09:04:48 UTC
I don't think this is the correct fix for this because the custom runtime's msc.exe could require a corlib that's incompatible with the current processes mono.

A more reliable solution would be to either invoke the 'mcs' script (like it's done for the default runtime) or add the full-path of the custom runtime's 'mono'.

When compiling against a custom runtime, then XS knows that 'mono' path.
Comment 7 Lluis Sanchez 2014-03-18 10:20:46 UTC
I'm lowering priority because it is not a blocker for our customers.
Comment 8 Mikayla Hutchinson [MSFT] 2014-03-19 02:48:35 UTC
Martin, your argument is invalid because this only applies to mcs invoked from xbuild, and when using a parallel runtime, XS hosts xbuild on the parallel runtime.

*** This bug has been marked as a duplicate of bug 17820 ***
Comment 9 Martin Baulig 2014-03-19 09:27:43 UTC
Yeah, I had no idea it was actually invoking an external process using that runtime until I debugged it yesterday.

The reason why the fix apparently did not work for me was that this external process launches mcs, so I had to get that fix into my custom runtime.