1
Vote

Difference in Nullability of Value-Type Properties can Cause AccessViolationException when Mapping on 64-bit Systems

description

We have discovered a bug in the Map functionality that can, under certain circumstances, crash the application process with a System.AccessViolationException, presumably due to bad IL. Obviously pretty nasty, especially if "application process" means ASP.Net.

The problem will occur under the following circumstances (all of these must be true):
  1. You are mapping between objects of different classes.
  2. You have a property you are mapping that is a value type.
  3. The property is not nullable in the source class, but is nullable in the target class.
  4. You run in a 64-bit environment.
If you call MapProperties in that scenario you will get a System.AccessViolationException.

Here’s an example:
using System;
using Fasterflect;

namespace ReflectorBug {
    public class SourceClass {
        public DateTime LastModifiedTimestamp { get; set; }
    }

    public class TargetClass
    {
        public int SimpleProperty { get; set; }
        public DateTime? LastModifiedTimestamp { get; set; }
    }

    class Program
    {
        static void Main(string[] args)
        {
            Console.Out.WriteLine("Process is 64-bit? " + System.Environment.Is64BitProcess);
            SourceClass s = new SourceClass();
            TargetClass t = new TargetClass();
            s.MapProperties(t);
            Console.Out.WriteLine("I survived!");
            Console.In.ReadLine();
        }
    }
}
On a 64-bit machine, you’ll never get to the “I survived” output. This has been verified on Fasterflect 2.1.2 and 2.1.3.

The obvious fix for us will be ensure that the types are identical, however, there should be nothing we can do as developers using Fasterflect that can cause the runtime to fail.

comments