Unable to intercept in x64

Issue #1 resolved
Igal Tabachnik created an issue

I'm trying to use the Fluent API from within a test method. When executing it with ReSharper's test runner in "Auto" (x64) platform, calling Cop.Intercept() will cause an AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Setting the runner to x86 manually works fine!

Here's a minimal code:

[TestFixture]
public class MyTest
{
    [Test]
    public void Test_method_name()
    {
        Cop.AsFluent();

        typeof (MyTest).GetMethod("Hello").Override(context =>
        {
            Console.WriteLine("Hi there!");
            return null;
        });

        Cop.Intercept(); // in x64, an exception occurs here
    }

    public void Hello()
    {
    }
}

Run with ReSharper's test runner.

Comments (4)

  1. Ricardo Barbosa

    Hi Igal,

    This issue is certainly related to the fact that you're probably running on a machine with .NET 4.6 installed and as of this date we don't support RyuJIT yet (https://bitbucket.org/codecop_team/codecop/wiki/Home). As you know RyuJIT kicks-in instead of JIT64 for x64 apps under .NET 4.6

    The reason for our decision had to do with the fact that at the time of our development RyuJIT was still very buggy (and its not very stable yet).

    https://github.com/dotnet/coreclr/issues/1296

    http://blogs.msdn.com/b/dotnet/archive/2015/07/28/ryujit-bug-advisory-in-the-net-framework-4-6.aspx

    So on machines that have .NET 4.6 installed you have to disable RyuJIT for CodeCop to work under x64.

    3 options are possible, check the below link and see which one suits you best (I personally under my dev machine have the registry option) https://github.com/Microsoft/dotnet/blob/master/docs/testing-with-ryujit.md

    Please tell us if that did the job for you.

    Thanks,

    RIcardo

  2. Ricardo Barbosa

    Hi Igal,

    Yes we do have plans to get it working with RyuJIT, we just want it to mature more.

    Makes sense what you say, in fact we already detect it in unmanaged code so there's no reason why we shouldn't be doing that earlier in the pipeline.

    Good catch! :)

    I will close this issue now, if it still persists (with I think it won't) please re-open it.

  3. Log in to comment