- Home /
Another Internal Compiler Error
I am using Unity 4 on a Mac.
I am getting an Internal Compiler Error. I did a search here and there are a lot of them. I tried to further refine my search to include my particular error and didn't get any smaller result set even though when I look at many of the other posts about this I don't see my stack trace as the same as the others. Therefore I am posting here. Sorry if this has already been answered as I couldn't find it.
I am trying to port some business logic code from a desktop C# application. I have slowly brought over the single classes one at a time, but can't pin down exactly when the internal compiler error triggered because I had brought over several classes and was fixing missing things in them until they were all fixed and then the internal compiler error showed up.
Mainly I want to know how do I figure this out? The stack trace doesn't help me any because I have no idea which of my source files it is working on when the error occurs. What do I do?
Stack Trace:
Internal compiler error. See the console log for more information. output was:Stacktrace:
at (wrapper managed-to-native) System.Type.MakeGenericType (System.Type,System.Type[]) <0x00004> at (wrapper managed-to-native) System.Type.MakeGenericType (System.Type,System.Type[]) <0x00004> at System.Type.MakeGenericType (System.Type[]) <0x00144> at Mono.CSharp.GenericTypeExpr.DoResolveAsTypeStep (Mono.CSharp.IMemberContext) <0x0009c> at Mono.CSharp.TypeExpr.ResolveAsTypeStep (Mono.CSharp.IMemberContext,bool) <0x0001e> at Mono.CSharp.Expression.ResolveAsBaseTerminal (Mono.CSharp.IMemberContext,bool) <0x0004d> at Mono.CSharp.Expression.ResolveAsTypeTerminal (Mono.CSharp.IMemberContext,bool) <0x0001b> at Mono.CSharp.Nullable.NullableType.DoResolveAsTypeStep (Mono.CSharp.IMemberContext) <0x000f6> at Mono.CSharp.TypeExpr.ResolveAsTypeStep (Mono.CSharp.IMemberContext,bool) <0x0001e> at Mono.CSharp.Expression.ResolveAsBaseTerminal (Mono.CSharp.IMemberContext,bool) <0x0004d> at Mono.CSharp.Nullable.NullableType.ResolveAsTypeTerminal (Mono.CSharp.IMemberContext,bool) <0x00018> at Mono.CSharp.Nullable.LiftedBinaryOperator.LiftResult (Mono.CSharp.ResolveContext,Mono.CSharp.Expression) <0x000a8> at Mono.CSharp.Nullable.LiftedBinaryOperator.ResolveUserOperator (Mono.CSharp.ResolveContext,System.Type,System.Type) <0x00039> at Mono.CSharp.Binary.ResolveOperator (Mono.CSharp.ResolveContext) <0x001a4> at Mono.CSharp.Binary.DoResolveCore (Mono.CSharp.ResolveContext,Mono.CSharp.Expression,Mono.CSharp.Expression) <0x00016> at Mono.CSharp.Nullable.LiftedBinaryOperator.DoResolve (Mono.CSharp.ResolveContext) <0x0014d> at Mono.CSharp.Expression.Resolve (Mono.CSharp.ResolveContext,Mono.CSharp.ResolveFlags) <0x0015b> at Mono.CSharp.Expression.Resolve (Mono.CSharp.ResolveContext) <0x00015> at Mono.CSharp.Binary.DoResolve (Mono.CSharp.ResolveContext) <0x008e0> at Mono.CSharp.Expression.Resolve (Mono.CSharp.ResolveContext,Mono.CSharp.ResolveFlags) <0x0015b> at Mono.CSharp.Expression.Resolve (Mono.CSharp.ResolveContext) <0x00015> at Mono.CSharp.Expression.ResolveBoolean (Mono.CSharp.ResolveContext,Mono.CSharp.Expression,Mono.CSharp.Location) <0x0001a> at Mono.CSharp.If.Resolve (Mono.CSharp.BlockContext) <0x0002a> at Mono.CSharp.Block.Resolve (Mono.CSharp.BlockContext) <0x0044e> at Mono.CSharp.Block.Resolve (Mono.CSharp.BlockContext) <0x0044e> at Mono.CSharp.ToplevelBlock.Resolve (Mono.CSharp.FlowBranching,Mono.CSharp.BlockContext,Mono.CSharp.ParametersCompiled,Mono.CSharp.IMethodData) <0x0008d> at Mono.CSharp.MethodData.Emit (Mono.CSharp.DeclSpace) <0x001ff> at Mono.CSharp.AbstractPropertyEventMethod.Emit (Mono.CSharp.DeclSpace) <0x00039> at Mono.CSharp.PropertyBase.Emit () <0x0007b> at Mono.CSharp.Property.Emit () <0x000b1> at Mono.CSharp.TypeContainer.EmitType () <0x00353> at Mono.CSharp.RootContext.EmitCode () <0x000aa> at Mono.CSharp.Driver.Compile () <0x00782> at Mono.CSharp.Driver.Main (string[]) <0x0008f> at (wrapper runtime-invoke) .runtime_invoke_int_object (object,intptr,intptr,intptr) <0x00043>
It there any way to get technical support from Unity faster than waiting here? I am blocked on my project and not sure where to go to get help beyond posting here.
Internal Compiler Errors seem to be an advanced issue that would warrant direct tech support.
If your project is not knee-deep in Unity 4, my advice to you is downgrade and rollback, until Unity irons out some critical bugs.
I have experienced other issues that convinced me that version 4 is not production quality yet.
https://store.unity3d.com/products/support. If your purchase premium support, you may care to send in the project that causes this error. The support $$anonymous$$m will just recommend that you binary chop the code until you track the offending file and line down otherwise. Also note that Unity uses $$anonymous$$ono and not .Net, so not all c# code will compile with Unity.
@DannyB Good suggestion, but in this case no dice. I reverted back to 3.5 and get the exact same internal compiler error.
I am in this EXACT situation, switching my own personal Tuple to a struct because with the ancient class library we're given I need to write all my own algebraics to maintain my personal standards of productivity (though even with rolling your own you get screwed with an invariant IEnumerable[T]... Do the Unity devs even understand the power of generics, proper variance, and FP? Probably not given how they seem to write their code, how generic $$anonymous$$onoBehaviors don't work correctly, how they base their APIs on reflection (!), etc, etc.) Oh, and my algebraic classes need to be structs because in Unity you need to avoid instantiations like the plague (even if it means tons of extra stack pushing) because of the insanely decrepit, alpha-quality GC. And I think I'm having issues with generics (specifically dictionary), but I'm not sure yet as all I get is an Internal Compiler Error.
(It's just beyond belief they didn't update the GC in 4.0. I mean... it's SO F---ING BAD and it affects EVERYTHING, especially the cash cow of mobile. And we're forced to write horribly hacky, boilerplate filled, maintenance nightmare code to deal with a problem (handling a s$$anonymous$$dy stream of short term allocations without GC hiccups) that has been SOLVED for nearly a decade. Who on the decision making $$anonymous$$m needs to get fired so we can get some work on the rotten foundations ahead of a gee-whiz new shader? I feel like I'm in a time warp to 1999 doing freaking OBJECT POOLING and indexed loops ins$$anonymous$$d of the beautifully pure and insanely productive glory of stuff like: myCollection.where().select().aggregate() because the GC will eventually choke on a couple tiny objects that each exist for a hundredth of a millisecond.
WHO NEEDS TO GET FIRED FOR THIS TO GET FIXED!???! THIS IS A SOLVED PROBLE$$anonymous$$ THAT PUTS NO BURDEN ON END USERS!!! EVEN ARTISTS AND $$anonymous$$ANAGERS WHO DON'T $$anonymous$$NOW WTF A GC IS $$anonymous$$NOW HICCUPS SUC$$anonymous$$ AND WASTING DEVELOPER TI$$anonymous$$E ON TO TRYING TO $$anonymous$$INI$$anonymous$$IZE THE$$anonymous$$ DOESN'T ADD ANY VALUE TO THE PRODUCT OR THE BOTTO$$anonymous$$ LINE! WHO THE HELL NEEDS TO GET FIRED FOR THIS TO GET FIXED!?!!!?)
Answer by Hotshot10101 · Dec 06, 2012 at 05:20 PM
EDITED:
From everything I can tell these Internal Compiler errors happen when I try to include a .dll file that requires .NET functionality that is higher than 2.0 and part of the bleeding edge stuff included in Unity's mono. That is probably why it is called bleeding edge, eh?
Anyway, the answer is just trial and error. Some newer .NET stuff works and some just doesn't even though it is included and supposedly "in there". <<<<<
I am having to put this in an answer spot because I can't format code and such in a comment.
I have discovered the lines of code that are causing the Internal compiler error. I just don't know how to solve it.
I have created my own Tuple class because it is not in Unity. It is defined as follows:
using System;
namespace System
{
// This is a very minimalistic implementation of Tuple'2 that allows us
// to compile and work on versions of .Net eariler then 4.0.
public struct Tuple<TItem1, TItem2>
{
public Tuple(TItem1 item1, TItem2 item2)
{
this = new Tuple<TItem1, TItem2>();
this.Item1 = item1;
this.Item2 = item2;
}
public TItem1 Item1 { get; private set; }
public TItem2 Item2 { get; private set; }
public override bool Equals(object obj)
{
if (obj is Tuple<TItem1, TItem2>)
{
Tuple<TItem1, TItem2> that = (Tuple<TItem1, TItem2>)obj;
return object.Equals(this.Item1, that.Item1) && object.Equals(this.Item2, that.Item2);
}
else
{
return false;
}
}
public override int GetHashCode()
{
return ((this.Item1 != null) ? this.Item1.GetHashCode() : 0) ^ ((this.Item2 != null) ? this.Item2.GetHashCode() : 0);
}
public static bool operator ==(Tuple<TItem1, TItem2> left, Tuple<TItem1, TItem2> right)
{
return left.Equals(right);
}
public static bool operator !=(Tuple<TItem1, TItem2> left, Tuple<TItem1, TItem2> right)
{
return !left.Equals(right);
}
}
// This is a very minimalistic implementation of Tuple'3 that allows us
// to compile and work on versions of .Net eariler then 4.0.
public struct Tuple<TItem1, TItem2, TItem3>
{
public Tuple(TItem1 item1, TItem2 item2, TItem3 item3)
{
this = new Tuple<TItem1, TItem2, TItem3>();
this.Item1 = item1;
this.Item2 = item2;
this.Item3 = item3;
}
public TItem1 Item1 { get; private set; }
public TItem2 Item2 { get; private set; }
public TItem3 Item3 { get; private set; }
public override bool Equals(object obj)
{
if (obj is Tuple<TItem1, TItem2, TItem3>)
{
Tuple<TItem1, TItem2, TItem3> that = (Tuple<TItem1, TItem2, TItem3>)obj;
return object.Equals(this.Item1, that.Item1) && object.Equals(this.Item2, that.Item2) && object.Equals(this.Item3, that.Item3);
}
else
{
return false;
}
}
public override int GetHashCode()
{
return ((this.Item1 != null) ? this.Item1.GetHashCode() : 0) ^ ((this.Item2 != null) ? this.Item2.GetHashCode() : 0) ^ ((this.Item3 != null) ? this.Item3.GetHashCode() : 0);
}
public static bool operator ==(Tuple<TItem1, TItem2, TItem3> left, Tuple<TItem1, TItem2, TItem3> right)
{
return left.Equals(right);
}
public static bool operator ==(Tuple<TItem1, TItem2, TItem3> left, object right)
{
return left.Equals(right);
}
public static bool operator !=(Tuple<TItem1, TItem2, TItem3> left, Tuple<TItem1, TItem2, TItem3> right)
{
return !left.Equals(right);
}
public static bool operator !=(Tuple<TItem1, TItem2, TItem3> left, object right)
{
return !left.Equals(right);
}
}
}
In the file that is cause the problem I have a List of those Tuples like so:
private List<Tuple<int, UInt32, byte[]>> Arguments;
Now here are the lines of code that cause the internal compiler error:
var f = Arguments.FirstOrDefault(a => a.Item3 != null);
if (f == null)
throw new NotSupportedException("No chunk in this SerialCommand!");
Specifically it is the if (f == null)
If I change that line to something else the internal compiler error goes away. I am guessing it has something to do with the fact that FirstOrDefault is returning something the compiler is not able to resolve properly.
The big question is what do I do about it?
BTW I've found out what causes many of these internal errors.
It appears that Generic parameter usage causes the problem when there is a choice of multiple possible implementations. I've fixed it by writing explicit implementations for every parameter list and by never allowing default parameters.
Coroutines that generate warnings such as unreachable code or unused variables, or using a try/catch in a coroutine, can sometimes create internal compiler errors in unity.
Yeah, $$anonymous$$ono seems to have trouble sometimes with multiple implementations of a function, when one or more of them have generics-based parameters.
This is what caused the internal compiler error for me: (the below is trimmed, so hopefully I didn't leave out anything important)
public struct P<T>
{
public readonly T[] mBuffer;
public static bool operator ==(P<T> left, P<T> right)
{
return left.mBuffer == right.mBuffer;
}
public static bool operator !=(P<T> left, P<T> right)
{
return left.mBuffer != right.mBuffer;
}
}
class C$$anonymous$$atchFinder
{
public P<byte> mBuffer;
bool LzInWindow_Create() { return mBuffer != null; } <<< adding this line causes the 'internal compiler error'
}
For now, my best fix is just to remove the "==" and "!=" operators from the class, override the "Equals" method to have equivalent comparing, and then call that method every place the "==" and "!=" operators are currently used.
Answer by Venryx · Feb 27, 2014 at 08:00 PM
I've been having internal compiler errors in my project also, and there are a couple things I've found that could help.
First, there is a technique which works well for narrowing-down where the internal compiler error happens.
First the thought process:
A) I noticed that compiler errors showing up in Visual Studio, when I attempted to build the project there (which failed because Unity hadn't built the DLL file, btw), were not showing up in the Unity console/error log.
B) This made me realize that the internal compiler error must be happening at some specific line in some specific file, and that once it hit that line, it stopped compiling the rest of the files. (and thus it never noticed the normal code issues (e.g. "int i = 0 / 0;") that Visual Studio picked up)
C) I looked into the Unity Editor logs, and noticed that the files were all being sent to the compiler in alphabetical order--in other words, in basically the same order you see them in the Project view. (the one difference being how they handle capital letters--Unity and Visual Studio consider 'a' to be before 'B', whereas the compiler considers 'a' to be after 'B', since 'B' is capitalized, and it always puts capitalized letters first (presumably because capitalized letters come first in the character map))
D) I realized that I could find which file the 'internal compiler error' happened in by intentionally creating normal compile errors at the bottom of each file, in turn, until I saw the normal error not show up in the Console. (indicating that it came after the internal-compiler-error-causing line)
So now:
Tip #1) The technique.
If you get an 'internal compiler error':
1) Place the following code at the very bottom of the first (alphabetically speaking) script file: (in other words, the top-most script file in the Project view)
class CompileBreaker { int i = 0 / 0; }
2) If you still get the 'internal compiler error', then the issue is somewhere in the file. (you can try placing the CompileBreaker at the top, just to make sure) If not, then remove the CompileBreaker code from the file, and add it to the bottom of the next file.
3) Repeating steps 1 and 2 for each script file, in alphabetical order.
The first time I used this technique, (which was just a few minutes ago), I was pretty lucky. I found the cause of my 'internal compiler error' in the second file, "Core.cs". Which brings me to my next point, which is that...
Tip #2) The Mono compiler for Unity apparently has an issue with partial classes.
Here is the file I found to have caused the internal compiler error, with the error-causing line marked:
using System;
namespace ManagedLzma.LZMA.Master
{
public static partial class LZMA // <<< the line that caused the 'internal compiler error'
{
[System.Diagnostics.Conditional("SHOW_DEBUG_INFO")]
internal static void DebugPrint(string format, params object[] args)
{
System.Diagnostics.Debug.WriteLine(String.Format(format, args));
}
internal static void Print(string format, params object[] args)
{
System.Diagnostics.Debug.WriteLine(String.Format(format, args));
}
}
}
class CompileBreaker { int i = 0 / 0; } // my CompileBreaker code that wasn't reached
I removed the word "partial" from the line, and changed the class name to "LZMA_RenamedForNow", and the compiler successfully reached the CompileBreaker code at the bottom. I then moved the CompileBreaker code to the next file, found the same issue (with it having "partial" class declarations), and fixed it. Moved the CompileBreaker to the next file. And so on.
Each time the CompileBreaker code is reached, you know the code up to that point is fine, so you just move it to the bottom of the next file.
It's worked really well for helping me solve this sort of problem, that is otherwise almost pure guesswork. (before this I was trying to delete and comment out files and code blocks, but that became very difficult because the library with the issues has dozens of classes which are interlinked with each other--causing early, normal compile errors, that blocked my ability to see where the 'internal compiler error' was lying (since the 'internal compiler error' is only seen if it doesn't encounter normal errors first))
Anyway, hope this helps anyone still having issues with finding where their project's 'internal compiler errors' lie.
I have to say that your "Tip" is rather brilliant. $$anonymous$$udos!
Answer by Tarlius · Feb 27, 2013 at 06:24 AM
It sounds like compiler might be confused and "optimising" one of the implementations of a Generic that you "aren't using" away. Theres a place you can add exceptions to this, to force the compiler to include a Generic implementation your code is using that it can't find, but I can't find it right now.
If this is the problem, be glad its crashing the compiler... When we had the problem at work in Unity 3 it was a runtime error... :/
What might help you is if you explicitly specify the you are expecting in FirstOrDefault. Ie:
Arguments.FirstOrDefault<Tuple<int, UInt32, byte[]>(a => a.Item3 != null); // I think?
If that doesn't work, you could try making a proper, "well-defined" delegate instead of a linq expression that the compiler tries to work out the type of.
Your answer
Follow this Question
Related Questions
Internal Compiler Error #3 (ILGenerator Emit Issue) 3 Answers
Internal Compiler Error 1 Answer
Warning messages are turning into Internal Compiler Errors...? 6 Answers
Internal Compiler Error again 1 Answer
Internal Compiler Error 0 Answers