Assertion: should not be reached at mini-trampolines.c:422

Hi everyone,

I have been working on getting a .NET codebase with generics working on an iOS device using Unity 3.5.7f6 and running into this problem.
(I have to fork over money to try Unity 4 on the device but as far as I know it has the same version of mono):

  • Assertion: should not be reached at mini-trampolines.c:422

It looks like this is the file in question, since there is a g_assert_not_reached(); invocation on line 442 . (BTW it would be nice if UT said somewhere which version of Unity used which version of mono on the github site, so I don’t have to try to guess among a kajillion branches. [edit: someone from UT mentioned unity-trunk and another branch, thanks.])

Disassembly then reports a EXC_BAD_ACCESS in g_logv, which I think is not the main issue here. I believe I saw somewhere that g_assert_not_reached (); was doing this, and it was fixed in a version of mono later than the 2.6.5.

So my question is, why is this assert failure being reached? It looks like some kind of code for handling generic methods, and JIT, which is not supposed to be in play for AOT. Usually it gives a sensical answer, though when trying to use a JIT method. (BTW, It looks like several improvements have been made to mini-trampolines since 2.6.5, but alas, we are stuck with the old version.)

Hmm I may be onto something that was causing a crash inside Unity related to casting an unknown object of a concrete class to its covariant generic interface (that inherits from a nongeneric interface), and then accessing a member property which returns the generic type. If I instead cast it to the nongeneric interface, which has no bases, and access its member property, which returns an interface rather than a generic type (and then cast that interface to my desired generic type), I avoided two crashes in hitting play in the Unity editor. Now to test on an iPad…

I narrowed things down and created a little snippet that can recreate the crash. (I passed this onto Unity3D’s QA team and they are looking into it.) I tried on a recent version of mono (2.10.something) outside of Unity on Mac OS X and it doesn’t crash.

You can find the code here, which uses a covariant interface:

Teaser:

public interface IInterface { new T Obj { get; } }

var tc = new TestClass(); // IInterface

UnityEngine.Debug.Log(“CrashTest 1 (TEST1)”);
IInterface iObj = tc;

UnityEngine.Debug.Log(“CrashTest 2”);
UnityEngine.Debug.Log("CrashTest iObj.Obj = (CRASHES): " + iObj.Obj);

Note: since this is the iOS forum, it should be noted these crashes occur in the Mac editor (and perhaps with Mono on PC as well.)

Note: I also tried taking out the base interface, IInterface, and the new keyword on the property, but got the same crash.

I’m running into the same crashing problem, only when running on iOS devices, using Unity 4.1.3f3, Mono 2.10.2. Did Unity’s QA team get back to you?

On March 13, Zbignev from QA reproduced the issue using my script and said he would pass it on to the developers, but I haven’t heard anything since then.

I am not sure if this is something they would try to fix until they upgrade to a new Mono version. (I haven’t tested whether this is fixed in newer versions of mono.) I think it is pretty obscure stuff in the bowels of JIT but not really JIT AOT code with IMT. (Zoltran Varga is the mono developer who has worked on this area.)

Makes sense–here’s hoping they upgrade to a new Mono version in the not-too-distant future.

For the benefit of anyone else who happens across this thread as I did after experiencing the same symptom, I isolated the problem in my project to calling extension methods on interfaces (I haven’t had any problem calling properties–yet). The crash occurs not just with extension methods on my own interfaces, but with standard .NET extension methods on standard .NET interfaces (like all of the IEnumerable extension methods in the System.Linq namespace).

So far I’ve been able to work around the issue by avoiding extension methods on interfaces entirely. For extension methods I wrote myself, it’s not enough simply to refrain from calling them: I actually have to comment out or delete the extension method declarations. For extension methods that come from the Framework (like the IEnumerable extension methods), simply not calling them is sufficient to avoid the crash.