devbox
Cpp五条
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

CoreCLR源码探索(六) NullReferenceException是如何发生的

作者：Cpp五条 | 2024-02-17 05:55:30

赞

踩

coreclr exception

NullReferenceException可能是.Net程序员遇到最多的例外了, 这个例外发生的如此频繁,以至于人们付出了巨大的努力来使用各种特性和约束试图防止它发生, 但时至今日它仍然让很多程序员头痛, 今天我将讲解这个令人头痛的例外是如何发生的.

可以导致NullReferenceException发生的源代码

我们先来看看什么样的代码可以导致NullReferenceException发生:

第一份代码, 调用函数时this等于null导致例外发生

  1. using System;namespace ConsoleApp1{    class Program
  2.     {        public class MyClass
  3.         {             public int MyMember;            public void MyMethod() { }
  4.         }        
  5.         static void Main(string[] args)        {
  6.             MyClass obj = null;
  7.             obj.MyMethod();
  8.         }
  9.     }
  10. }

第二份代码, 访问成员时this等于null导致例外发生

  1. using System;namespace ConsoleApp1{    class Program
  2.     {        public class MyClass
  3.         {             public int MyMember;            public void MyMethod() { }
  4.         }        
  5.         static void Main(string[] args)        {
  6.             MyClass obj = null;
  7.             Console.WriteLine(obj.MyMember);
  8.         }
  9.     }
  10. }

观察生成的IL代码

再来看看生成的IL:

第一份代码的IL

  1. .method private hidebysig static 
  2.     void Main (
  3.         string[] args
  4.     ) cil managed 
  5. {
  6.     // Method begins at RVA 0x2050
  7.     // Code size 11 (0xb)
  8.     .maxstack 1
  9.     .entrypoint
  10.     .locals init (
  11.         [0] class ConsoleApp1.Program/MyClass
  12.     )
  13.  
  14.     IL_0000: nop
  15.     IL_0001: ldnull
  16.     IL_0002: stloc.0
  17.     IL_0003: ldloc.0
  18.     IL_0004: callvirt instance void ConsoleApp1.Program/MyClass::MyMethod()
  19.     IL_0009: nop
  20.     IL_000a: ret
  21. } // end of method Program::Main

第二份代码的IL

  1. .method private hidebysig static 
  2.     void Main (
  3.         string[] args
  4.     ) cil managed 
  5. {
  6.     // Method begins at RVA 0x2050
  7.     // Code size 16 (0x10)
  8.     .maxstack 1
  9.     .entrypoint
  10.     .locals init (
  11.         [0] class ConsoleApp1.Program/MyClass
  12.     )
  13.  
  14.     IL_0000: nop
  15.     IL_0001: ldnull
  16.     IL_0002: stloc.0
  17.     IL_0003: ldloc.0
  18.     IL_0004: ldfld int32 ConsoleApp1.Program/MyClass::MyMember
  19.     IL_0009: call void [System.Console]System.Console::WriteLine(int32)
  20.     IL_000e: nop
  21.     IL_000f: ret
  22. } // end of method Program::Main

看出什么了吗? 看不出吧, 我也看不出, 这代表了null检查不是在IL层面实现的, 我们需要继续往下看.

观察生成的汇编代码

看生成的汇编代码:

第一份代码生成的汇编 (架构不同生成的代码也不同, 以下代码是windows x64生成的)

    10:         static void Main(string[] args) {00007FF9F5C30482 56                   push        rsi  00007FF9F5C30483 48 83 EC 30          sub         rsp,30h  00007FF9F5C30487 48 8B EC             mov         rbp,rsp  00007FF9F5C3048A 33 C0                xor         eax,eax  00007FF9F5C3048C 48 89 45 20          mov         qword ptr [rbp+20h],rax  00007FF9F5C30490 48 89 45 28          mov         qword ptr [rbp+28h],rax  00007FF9F5C30494 48 89 4D 50          mov         qword ptr [rbp+50h],rcx  00007FF9F5C30498 83 3D 49 48 EA FF 00 cmp         dword ptr [7FF9F5AD4CE8h],0  00007FF9F5C3049F 74 05                je          00007FF9F5C304A6  00007FF9F5C304A1 E8 1A B5 C0 5F       call        00007FFA5583B9C0  00007FF9F5C304A6 90                   nop      11:             MyClass obj = null;00007FF9F5C304A7 33 C9                xor         ecx,ecx  00007FF9F5C304A9 48 89 4D 20          mov         qword ptr [rbp+20h],rcx      12:             obj.MyMethod();00007FF9F5C304AD 48 8B 4D 20          mov         rcx,qword ptr [rbp+20h]  00007FF9F5C304B1 39 09                cmp         dword ptr [rcx],ecx  00007FF9F5C304B3 E8 E8 FB FF FF       call        00007FF9F5C300A0  00007FF9F5C304B8 90                   nop      13:         }

第二份代码生成的汇编

    10:         static void Main(string[] args) {00007FF9F5C20B22 56                   push        rsi  00007FF9F5C20B23 48 83 EC 30          sub         rsp,30h  00007FF9F5C20B27 48 8B EC             mov         rbp,rsp  00007FF9F5C20B2A 33 C0                xor         eax,eax  00007FF9F5C20B2C 48 89 45 20          mov         qword ptr [rbp+20h],rax  00007FF9F5C20B30 48 89 45 28          mov         qword ptr [rbp+28h],rax  00007FF9F5C20B34 48 89 4D 50          mov         qword ptr [rbp+50h],rcx  00007FF9F5C20B38 83 3D A9 41 EA FF 00 cmp         dword ptr [7FF9F5AC4CE8h],0  00007FF9F5C20B3F 74 05                je          00007FF9F5C20B46  00007FF9F5C20B41 E8 7A AE C1 5F       call        00007FFA5583B9C0  00007FF9F5C20B46 90                   nop      11:             MyClass obj = null;00007FF9F5C20B47 33 C9                xor         ecx,ecx  00007FF9F5C20B49 48 89 4D 20          mov         qword ptr [rbp+20h],rcx      12:             Console.WriteLine(obj.MyMember);00007FF9F5C20B4D 48 8B 4D 20          mov         rcx,qword ptr [rbp+20h]  00007FF9F5C20B51 8B 49 08             mov         ecx,dword ptr [rcx+8]  00007FF9F5C20B54 E8 87 FB FF FF       call        00007FF9F5C206E0  00007FF9F5C20B59 90                   nop      13:         }

从汇编我们可以看出点端倪了, 注意第一份代码中的以下指令

00007FF9F5C304B1 39 09                cmp         dword ptr [rcx],ecx  

和第二份代码中的以下指令

00007FF9F5C20B51 8B 49 08             mov         ecx,dword ptr [rcx+8]  

在第一份代码中多了一个奇怪的cmp指令,
这个cmp比较了rcx自身但是却不使用比较的结果(后续je, jne等等),
这个指令正是null检查的真面目,
rcx寄存器保存的是obj对象的指针, 也是下面的call指令的第一个参数(this),
如果rcx等于0(obj等于null)时, 这条指令就会执行失败.

在第二份代码中mov ecx,dword ptr [rcx+8]指令的作用是把rcx保存的obj的MyMember成员的值移到ecx,
可以理解为c语言的int myMember = obj->MyMember;或int myMember = *(int*)(((char*)obj)+8),
这里的8是MyMember距离对象开头的偏移值,
想象一下如果obj等于null, rcx+8等于8,
因为内存地址8上面不存在任何内容, 这条指令就会执行失败.
因为这条指令已经带有检查null的作用, 所以第二份代码中你看不到像第一份代码中的cmp指令.

熟悉c语言的可能会问, 这样的指令执行失败以后程序不会立刻退出吗?
答案是会, 如果你不做特殊的处理, 访问((MyClass*)NULL)->MyMember会导致程序立刻退出.
那么在CoreCLR中是如何处理的?

指令执行失败以后

CPU指令执行失败以后(内存访问失败, 除0等)时, 会传递一个硬件例外给内核, 然后内核会结束对应的进程.
但在结束之前它会允许进程补救, 补救的方法Windows和Linux都不一样.

在Linux上可以通过捕捉SIGSEGV处理内存访问失败, 示例代码如下

  1. #include <signal.h>#include <stdio.h>#include <stdlib.h>#include <setjmp.h>jmp_buf recover_point;static void sigsegv_handler(int sig, siginfo_t* si, void* unused) {    fprintf(stderr, "catched sigsegv\n");
  2.     longjmp(recover_point, 1);
  3. }  int main() {      struct sigaction action;
  4.     action.sa_handler = NULL;
  5.     action.sa_sigaction = sigsegv_handler;
  6.     action.sa_flags = SA_SIGINFO;
  7.     sigemptyset(&action.sa_mask);       if (sigaction(SIGSEGV, &action, NULL) != 0) {
  8.         perror("bind signal handler failed");             abort();
  9.     }    
  10.     if (setjmp(recover_point) == 0) {              int* ptr = NULL;
  11.         *ptr = 1;
  12.     } else {        printf("recover success\n");;
  13.     }    return 0;
  14. }

而在Windows上可以通过注册VectoredExceptionHandler处理硬件异常, 示例代码如下

  1. #include "stdafx.h"#include <Windows.h>#include <setjmp.h>void* gVectoredExceptionHandler = NULL;
  2. jmp_buf gRecoverPoint;LONG WINAPI MyVectoredExceptionHandler(PEXCEPTION_POINTERS pExceptionInfo){    if (pExceptionInfo->ExceptionRecord->ExceptionCode == STATUS_ACCESS_VIOLATION)
  3.     {        fprintf(stderr, "catched access violation\n");
  4.         longjmp(gRecoverPoint, 1);
  5.     }    return EXCEPTION_CONTINUE_SEARCH;
  6. }int main(){
  7.     gVectoredExceptionHandler = AddVectoredExceptionHandler(
  8.         TRUE, (PVECTORED_EXCEPTION_HANDLER)MyVectoredExceptionHandler);    if (setjmp(gRecoverPoint) == 0)
  9.     {        int* ptr = NULL;
  10.         *ptr = 1;
  11.     }    else
  12.     {        printf("recover success\n");
  13.     }    return 0;
  14. }

在上面的代码中我使用了longjmp来从异常中恢复, 这是最简单的做法但也会带来很多问题, 接下来我们看看CoreCLR会如何处理这些异常.

CoreCLR中的处理 (Linux, OSX)

我们先来看Linux上CoreCLR是如何处理的, 以下代码来源于CoreCLR 1.1.0, OSX上的处理逻辑和Linux一样.

首先CoreCLR会注册SIGSEGV的处理器, 在pal\src\exception\signal.cpp中可以找到以下的代码

  1. BOOL SEHInitializeSignals(DWORD flags){
  2.     TRACE("Initializing signal handlers\n");    /* we call handle_signal for every possible signal, even         if we don't provide a signal handler.         handle_signal will set SA_RESTART flag for specified signal.         Therefore, all signals will have SA_RESTART flag set, preventing          slow Unix system calls from being interrupted. On systems without          siginfo_t, SIGKILL and SIGSTOP can't be restarted, so we don't          handle those signals. Both the Darwin and FreeBSD man pages say           that SIGKILL and SIGSTOP can't be handled, but FreeBSD allows us          to register a handler for them anyway. We don't do that.           see sigaction man page for more details       */
  3.     handle_signal(SIGILL, sigill_handler, &g_previous_sigill); 
  4.     handle_signal(SIGTRAP, sigtrap_handler, &g_previous_sigtrap);
  5.     handle_signal(SIGFPE, sigfpe_handler, &g_previous_sigfpe);
  6.     handle_signal(SIGBUS, sigbus_handler, &g_previous_sigbus);
  7.     handle_signal(SIGSEGV, sigsegv_handler, &g_previous_sigsegv);
  8.     handle_signal(SIGINT, sigint_handler, &g_previous_sigint);
  9.     handle_signal(SIGQUIT, sigquit_handler, &g_previous_sigquit);

这里除了注册SIGSEGV以外还会注册其他信号的处理器, 接下来看sigsegv_handler的内容:

common_signal_handler的内容:

继续追下去会很长, 这里就只贴跟踪的调用流程了:


  跳过去以后会继续处理, 不再返回

总结:

  • 在Linux上

    • 这是为了可以和Windows共享处理的代码

    • 如果对象是null并且访问对象的函数或者成员, 会触发SIGSEGV信号

    • CoreCLR捕捉到SIGSEGV信号后会根据信号生成类似Windows形式的EXCEPTION_POINTERS结构体

    • 处理例外时, 根据例外代码(0xC0000005L)转换为CLR中的NullReferenceException的对象

    • 回滚堆栈和调用finally中的代码

    • 跳到对应的处理例外(catch)的代码

例外处理不是这一篇的重点所以这里我就不详细解释了(目前还未弄清楚).

CoreCLR中的处理 (Windows)

在Windows上CoreCLR会注册一个VectoredHandler用于处理硬件例外:

这是vm\excep.cpp中的CLRAddVectoredHandlers函数, 启动时会调用

  1. void CLRAddVectoredHandlers(void){#ifndef FEATURE_PAL
  2.  
  3.     // We now install a vectored exception handler on all supporting Windows architectures.
  4.     g_hVectoredExceptionHandler = AddVectoredExceptionHandler(TRUE, (PVECTORED_EXCEPTION_HANDLER)CLRVectoredExceptionHandlerShim);    if (g_hVectoredExceptionHandler == NULL)
  5.     {
  6.         LOG((LF_EH, LL_INFO100, "CLRAddVectoredHandlers: AddVectoredExceptionHandler() failed\n"));
  7.         COMPlusThrowHR(E_FAIL);
  8.     }
  9.  
  10.     LOG((LF_EH, LL_INFO100, "CLRAddVectoredHandlers: AddVectoredExceptionHandler() succeeded\n"));#endif // !FEATURE_PAL}

当硬件异常发生时会调用这个处理器, 代码同样在vm\excep.cpp,同样的, 继续跟下去会非常长我就只贴跟踪流程了:

总结:

  • 在Windows上

    • 如果对象是null并且访问对象的函数或者成员, 会触发硬件异常

    • CoreCLR通过CLRVectoredExceptionHandlerShim捕捉到异常

    • 调用原生的RaiseException抛出例外给ProcessCLRException处理

    • 处理例外时, 根据例外代码(0xC0000005L)转换为CLR中的NullReferenceException的对象

    • 回滚堆栈和调用finally中的代码

    • 跳到对应的处理例外(catch)的代码

特殊情况的null检查

注意到上面第二份代码中的访问异常是在访问了0x8的时候出现的吗?
想想如果成员在更后面的位置, 例如0x10000, 并且在0x10000有内容存在的时候还可以检测出来吗?
这里我模拟一下特殊情况下的null检查, 看看CoreCLR是否可以正确处理.

测试使用的代码:

运行时的汇编代码:

注意图中红框的部分, CoreCLR加了额外的cmp, 成功避过了使用VirtualAlloc设下的陷阱.

你也可能会问, 如果使用VirtualAlloc来在0x8分配内存可以骗过CoreCLR吗?
事实上VirtualAlloc不能在0x8分配内存, 可以分配到的虚拟内存地址有范围限制,
如果成员的位置大于最小可以分配的虚拟内存地址, 则CoreCLR会插入一个额外的检查, 所以这种情况是骗不过CoreCLR的.

性能测试

我们再来测下自动抛出NullReferenceException和手动抛出NullReferenceException性能有多大的差别

测试的代码如下:

  1. public static string GetString(){    return null;
  2. }public static void BenchmarkNullReferenceException(){      for (int x = 0; x < 100000; ++x)
  3.     {        try
  4.         {                         string str = GetString();                int length = str.Length;
  5.         }               catch (Exception ex)
  6.         {
  7.         }
  8.     }
  9. }    public static void BenchmarkManualNullReferenceException() {           for (int x = 0; x < 100000; ++x)
  10.     {              try
  11.         {                   string str = GetString();                   if (str == null)
  12.             {                            throw new NullReferenceException();
  13.             }                     int length = str.Length;
  14.         }              catch (Exception ex)
  15.         {
  16.  
  17.         }
  18.     }
  19. }

测试结果:

  1. BenchmarkNullReferenceException: 0.9024312s
  2. BenchmarkManualNullReferenceException: 0.9746265s

测试的结果比较出乎意料,
BenchmarkNullReferenceException和BenchmarkManualNullReferenceException在Debug和Release配置下所花的时间都是1秒左右,
这也说明了处理硬件异常的消耗相对于处理CLR异常的消耗并不大, 甚至还比手动抛出的消耗更小.

为什么要这样实现null检查

最常见也是最容易理解的null检查可能是在底层生成类似test rcx, rcx; jne 1f; call ThrowNullReferenceException; 1:的代码,
然而CoreCLR并不采用这种办法, 我个人推测有这些原因:

  • 可以节省生成的代码大小, 一条检查用的cmp指令只占2个字节

  • 可以提升检查性能, 例如访问成员时直接使用mov 寄存器, [对象寄存器+成员偏移值]即可同时取出值并检查是否null, 不需要额外的检查指令

  • 可以捕捉非托管代码中的异常, 调用使用c写的代码中发生了内存访问错误也可以捕捉到

参考链接

这篇文章参考了以下链接, 并且还在github上向CoreCLR提过了相关问题

这篇相对来说比较易懂, 之前讲好的JIT篇要继续延期, 请大家耐心等待了.

相关文章：

原文地址：http://www.cnblogs.com/zkweb/p/6898627.html

        
 
 
 
.NET社区新闻，深度好文，微信中搜索dotNET跨平台或扫描二维码关注
声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/Cpp五条/article/detail/100671
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号