c# - significado - clr sql

¿Por qué el acceso a la memoria en el espacio de direcciones más bajo(aunque no nulo) se informa como NullReferenceException por.NET?

Question

Esto hace que se AccessViolationException una AccessViolationException :

using System;

namespace TestApplication
{
    internal static class Program
    {
        private static unsafe void Main()
        {
            ulong* addr = (ulong*)Int64.MaxValue;
            ulong val = *addr;
        }
    }
}

Esto hace que se lance una NullReferenceException :

using System;

namespace TestApplication
{
    internal static class Program
    {
        private static unsafe void Main()
        {
            ulong* addr = (ulong*)0x000000000000FF;
            ulong val = *addr;
        }
    }
}

Ambos son punteros inválidos y ambos violan las reglas de acceso a la memoria. ¿Por qué la NullReferenceException?

Answer 1

Esto es causado por una decisión de diseño de Windows tomada hace muchos años. Los 64 kilobytes inferiores del espacio de direcciones están reservados. Un acceso a cualquier dirección en ese rango se informa con una excepción de referencia nula en lugar de la violación de acceso subyacente. Esta fue una buena elección, un puntero nulo puede producir lecturas o escrituras en direcciones que en realidad no son cero. Leyendo un campo de un objeto de clase C ++, por ejemplo, tiene un desplazamiento desde el inicio del objeto. Si el puntero del objeto es nulo, el código bombardeará al leer en una dirección que sea mayor que 0.

C # no tiene el mismo problema, el lenguaje garantiza que se capture una referencia nula antes de poder llamar a un método de instancia de una clase. Sin embargo, esto es específico del idioma, no es una característica de CLR. Puede escribir código administrado en C ++ / CLI y generar referencias erróneas de puntero nulo que no sean cero. Llamar a un método en un objeto nullptr funciona. Ese método se ejecutará alegremente. Y llamar a otros métodos de instancia. Hasta que intente acceder a una variable de instancia o llamar a un método virtual, que requiere desreferenciar esto , entonces kaboom.

La garantía de C # es muy buena, hace que el diagnóstico de problemas de referencia nula sea mucho más fácil, ya que se generan en el sitio de la llamada y no bombardean en algún lugar dentro de un método anidado. Y es fundamentalmente más seguro, la variable de instancia puede no desencadenar una excepción en objetos extremadamente grandes cuando su desplazamiento es mayor que 64K. Bastante difícil de hacer en el código administrado por cierto, a diferencia de C ++. Pero no viene de forma gratuita, se explica en esta entrada de blog .

Answer 2

Esto puede ser un problema de semántica.

Su primer ejemplo es tratar de eliminar la referencia de un puntero cuyo contenido es la dirección Int64.MaxValue, no un puntero a una variable que tiene un valor de Int64.MaxValue.

Parece que está intentando leer el valor almacenado en la dirección Int64.MaxValue, que aparentemente no se encuentra en el rango que pertenece a su proceso.

¿Te refieres a algo como esto?

        static unsafe void Main(string[] args)
        {
            ulong val = 1;// some variable space to store an integer
            ulong* addr = &val;
            ulong read = *addr;

            Console.WriteLine("Val at {0} = {1}", (ulong)addr, read);

#if DEBUG 
            Console.WriteLine("Press enter to continue");
            Console.ReadLine();
#endif
        }

Answer 3

La CPU genera una excepción de referencia nula y una excepción de violación de acceso como una infracción de acceso. El CLR luego tiene que adivinar si la violación de acceso debe especializarse a una excepción de referencia nula o si debe dejarse como una violación de acceso más general.

Es evidente por los resultados que el CLR infiere que las violaciones de acceso en direcciones muy cercanas a 0 son causadas por una referencia nula. Porque casi con certeza fueron generados por una referencia nula más un desplazamiento de campo. Su uso de código inseguro engaña a esta heurística.

Answer 4

desde http://msdn.microsoft.com/en-us/library/system.accessviolationexception.aspx

Información de versión

Esta excepción es nueva en .NET Framework versión 2.0. En versiones anteriores de .NET Framework, una infracción de acceso en un código no administrado o en un código administrado no seguro se representa mediante una excepción NullReferenceException en un código administrado. También se lanza una NullReferenceException cuando se hace referencia a una referencia nula en el código administrado verificable, una ocurrencia que no implica corrupción de datos, y no hay manera de distinguir entre las dos situaciones en las versiones 1.0 o 1.1.

Los administradores pueden permitir que las aplicaciones seleccionadas vuelvan al comportamiento de .NET Framework versión 1.1. Coloque la siguiente línea en la sección Elemento del archivo de configuración para la aplicación:

other <legacyNullReferenceExceptionPolicy enabled = "1"/>