{"id":28733,"date":"2021-10-15T15:00:12","date_gmt":"2021-10-15T15:00:12","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cppblog\/?p=28733"},"modified":"2021-10-15T10:42:32","modified_gmt":"2021-10-15T10:42:32","slug":"a-race-condition-in-net-finalization-and-its-mitigation-for-cpp-cli","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/a-race-condition-in-net-finalization-and-its-mitigation-for-cpp-cli\/","title":{"rendered":"A Race Condition in .NET Finalization and its Mitigation for C++\/CLI"},"content":{"rendered":"

Abstract<\/h2>\n

There is a dormant race condition in .NET<\/code> which affects even single threaded code when finalizers are executed. The cause is primarily the fact that finalizers are called on a separate thread by .NET<\/code> and may access objects which have already been garbage collected due to aggressive lifetime determination by the .NET<\/code> JIT compiler in newer versions of the .NET<\/code> runtime.\nA solution for this problem, in the form of automatic generation of calls to System::GC::KeepAlive<\/code>, has been implemented in the Microsoft C++ compiler and is available in version 16.10 and later.<\/p><\/blockquote>\n

Introduction<\/h2>\n

C++\/CLI is primarily meant to be an interop language bridging the native\nand .NET<\/code> worlds efficiently. Consequently, a frequently occuring code\npattern is wrapping of native pointers in managed classes. E.g.<\/p>\n

class NativeClass { ... };\r\nref class ManagedClass {\r\n    ...\r\nprivate:\r\n    NativeClass* ptr;\r\n};<\/code><\/pre>\n
Often, the managed wrapper class will new<\/code> an instance of\nNativeClass<\/code>, which controls and accesses a system resource (e.g. a\nfile), uses the resources and to make sure that the resource is properly\nreleased back, delegates this task to the finalizer. Elaborating the\nabove example, we could have code like:<\/p>\n
 1  using Byte = System::Byte;\r\n 2  using String = System::String^;\r\n 3  using Char = System::Char;\r\n 4\r\n 5  class File {\r\n 6      FILE*   fp;\r\n 7  public:\r\n 8      explicit File(const Char* path, const Char* mode)\r\n 9      {\r\n10          fp = _wfopen(path, mode);\r\n11      }\r\n12      void Read() { ... }\r\n13      void Write(const void*, size_t) { ... }\r\n14      void Seek() { ... }\r\n15      void Close()\r\n16      {\r\n17          if (fp) {\r\n18              fclose(fp); fp = nullptr;\r\n19          }\r\n20      }\r\n21      ~File() { Close(); }\r\n22  };\r\n\r\n26   ref class DataOnDisk\r\n27   {\r\n28   public:\r\n29       DataOnDisk(String path, String mode)\r\n30       {\r\n31           cli::pin_ptr<const Char> path_ptr = PtrToStringChars(path);\r\n32           cli::pin_ptr<const Char> mode_ptr = PtrToStringChars(mode);\r\n33           ptr = new File(path_ptr, mode_ptr);\r\n34       }\r\n35       ~DataOnDisk() { this->!DataOnDisk(); }\r\n36       !DataOnDisk()\r\n37       {\r\n38           if (ptr) {\r\n39               delete ptr; ptr = nullptr;\r\n40           }\r\n41       }\r\n42       void Close() { this->!DataOnDisk(); }\r\n43       void WriteData(array<Byte>^ data) { ... }\r\n44   private:\r\n45       File*           ptr;  \/\/ Pointer to native implementation class.\r\n46   };<\/code><\/pre>\n
In the above code, class File<\/code> controls the actual file via the native\nC++ interface, while DataOnDisk<\/code> uses the native class to read\/write\nstructured data to file (details have been omitted for clarity). While\nClose<\/code> can be called explicitly when there is no more use for the file,\nthe finalizer is meant to do this when the DataOnDisk<\/code> object is\ncollected.<\/p>\n
As we shall see in the following section, while the above code appears\ncorrect, there is a hidden race condition that can cause program errors.<\/p>\n
Race Condition<\/h2>\n
Let us define the member WriteData<\/code> from the above code<\/p>\n
49  void DataOnDisk::WriteData(array<Byte>^ buffer)\r\n50  {\r\n51      pin_ptr<Byte> buffer_ptr = &buffer[0];\r\n52      this->ptr->Write(buffer_ptr, buffer->Length);\r\n53  } <\/code><\/pre>\n
This function itself might be called in this context:<\/p>\n
55  void test_write()\r\n56  {\r\n57      DataOnDisk^ dd = gcnew DataOnDisk(...);\r\n58      array<Byte>^ buf = make_test_data();\r\n59      dd->WriteData(buf);\r\n60  } <\/code><\/pre>\n
So far, nothing catches the eye or looks remotely dangerous. Starting\nfrom test_write<\/code>, let us examine what happens in detail.<\/p>\n
    \n
  1. A DataOnDisk<\/code> object is created (line 57), some test data is\ncreated and WriteData<\/code> is called to write this data to file (line\n59).<\/li>\n
  2. The WriteData<\/code> carefully pins the buffer array object (line 51)\nbefore taking the address of an element and calling the Write<\/code>\nmember function of the underlying native File<\/code> object. The pinning\nis important because we don’t want .NET<\/code>\u00a0to move the buffer bytes\nwhile the write is happening.<\/li>\n
  3. However, since the .NET<\/code>\u00a0garbage collector knows nothing about\nnative types, the ptr<\/code> field of DataOnDisk<\/code> is just a bit pattern\nwith no other meaning attached. The .NET<\/code>\u00a0JIT compiler has analyzed\nthe code and determined that the last use of the dd<\/code> object is to\naccess ptr<\/code> (line 52), before its value is passed as the implicit\nobject parameter of File::Write<\/code>. Following this reasoning by the\nJIT compiler, once the value of ptr<\/code> is fetched from the object,\nthe object dd<\/code> is no longer needed<\/em> and becomes eligible for\ngarbage collection.The fact that ptr<\/code> points to a live native\nobject is opaque to .NET<\/code>\u00a0because it does not track native\npointers.<\/li>\n
  4. From here onward, things can go wrong. The object dd<\/code> is scheduled\nfor collection and as part of the process, the finalizer is run,\ntypically on a second thread. Now, we have potentially two things\nhappening at the same time without any ordering between them, a\nclassic race condition: the Write<\/code> member function is executing and\nthe finalizer !DataOnDisk<\/code> is executing as well, the latter will\ndelete<\/code> the file object referenced by ptr<\/code> while File::Write<\/code> is\npossibly still running<\/em>, which can then result in a crash or other\nincorrect behavior.<\/li>\n<\/ol>\n
    Wait — Wha…?<\/h2>\n
    Several questions immediately come to mind:<\/p>\n
      \n
    • Is this a new bug?<\/em> Yes — and no. The issue has potentially been\naround since .NET<\/code>\u00a02.0.<\/li>\n
    • What changed?<\/em> The .NET<\/code>\u00a0JIT compiler started being aggressive\nwith lifetime determination in .NET<\/code>\u00a04.8. From the perspective of\nmanaged code, it is doing the right thing.<\/li>\n
    • But, this affects a core C++\/CLI native interop scenario. What can\nbe done?<\/em> Read on.<\/li>\n<\/ul>\n
      Solutions<\/h2>\n
      It is easy to see that when the call to Write<\/code> happens (line 52), if\nthis<\/code> is kept alive, the race condition disappears since dd<\/code> will no\nlonger be collected before the call to Write<\/code> returns. This could be\ndone in several different ways:<\/p>\n
        \n
      • Treat the change in the behavior of the JIT compiler as a bug and\nrevert back to old behavior.<\/em> Doing this requires a system update\nfor .NET<\/code>\u00a0and potentially disables optimizations. Freezing the\n.NET<\/code>\u00a0framework at version 4.7 is also an option but not one that\nwill work in the longer term, especially since the same JIT behavior\ncan happen in .NET<\/code>\u00a0Core<\/code> as well.<\/li>\n
      • Manually insert System::GC::KeepAlive(this)<\/code> calls where needed<\/em>.\nThis works but is error prone and requires examining the user source\nand changing it, so this is not a viable solution for large source\nbases.<\/li>\n
      • Have the compiler inject System::GC::KeepAlive(this)<\/code> calls, when\nneeded<\/em>. This is the solution we have implemented in the Microsoft\nC++ compiler.<\/li>\n<\/ul>\n
        Details<\/h2>\n
        We could brute-force a solution by issuing a call to KeepAlive<\/code> every\ntime we see a call to native function, but for performance reasons we\nwant to be more clever. We want to issue such calls where there is a\npossibility of a race condition but nowhere else. The following is the\nalgorithm that the Microsoft C++ compiler follows to determine if an\nimplicit KeepAlive<\/code> call is to be issued at a point in the code where:<\/p>\n
          \n
        • We are at a return statement or implicit return from a member\nfunction of a managed class;<\/li>\n
        • The managed class has a member of type ‘reference or pointer to\nunmanaged type’, including members in its direct or indirect base\nclasses, or embedded in members of class-types occuring anywhere in\nthe class hierarchy;<\/li>\n
        • A call to a function FUNC<\/code> is found in the current (managed member)\nfunction, which satisfies one or more of these conditions:<\/p>\n
            \n
          1. FUNC<\/code> doesn’t have a __clrcall<\/code> calling convention, or<\/li>\n
          2. FUNC<\/code> doesn’t take this<\/code> either as an implicit or explicit\nargument, or<\/li>\n
          3. A reference to this<\/code> doesn’t follow the call to FUNC<\/code><\/li>\n<\/ol>\n<\/li>\n<\/ul>\n
            In essence, we are looking for indicators that show this<\/code> is in no\ndanger of getting garbage collected during the call to FUNC<\/code>. Hence, if\nthe above conditions are satisfied, we insert a\nSystem::GC::KeepAlive(this)<\/code> call immediately following the call to\nFUNC<\/code>. Even though a call to KeepAlive<\/code> looks very much like a\nfunction call in the generated MSIL, the JIT compiler treats it as a\ndirective to consider the current object alive at that point.<\/p>\n
            How to get the fix<\/h2>\n
            The above Microsoft C++ compiler behavior is on by default<\/strong> in Visual\nStudio version 16.10<\/strong> and up but in in cases where unforeseen\nproblems occur due to the new implicit emission of KeepAlive<\/code> calls,\nthe Microsoft C++ compiler provides two escape hatches:<\/p>\n
              \n
            • the driver switch \/clr:implicitKeepAlive-<\/code>, which turns off all\nsuch calls in the translation unit. This switch is not available in\nproject system settings but must be added explicitly to the\ncommand-line option list\n(Property Pages > Command Line > Additional Options<\/code>).<\/li>\n
            • #pragma implicit_keepalive<\/code>, which provides fine-grained control\nover the emission of such calls at the function level.<\/li>\n<\/ul>\n
              A Final Nit<\/h2>\n
              The astute reader will have noted that there is still a possible race\ncondition at line 39. To see why, imagine that both the finalizer thread\nand user code call the finalizer at the same time. The possibility of a\ndouble-delete in this case is obvious. Fixing this requires a critical\nsection but is beyond the scope of this article and left to the reader\nas an exercise.<\/p>\n","protected":false},"excerpt":{"rendered":"
              Race conditions can occur in .NET finalization. This article explains the solution implemented in MSVC.<\/p>\n","protected":false},"author":67691,"featured_media":35994,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-28733","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cplusplus"],"acf":[],"blog_post_summary":"
              Race conditions can occur in .NET finalization. This article explains the solution implemented in MSVC.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/28733","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/67691"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=28733"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/28733\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/35994"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=28733"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=28733"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=28733"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}