global std::once_flag variables don't work with Visual Studio #4773

xfxyjwf · 2018-06-16T23:22:52Z

Symptom: statically built protoc binary check-fails.
#4409

[libprotobuf FATAL D:\Google-Protobuf\src\src\google\protobuf\generated_message_reflection.cc:2372] CHECK failed: file != NULL:

Cause:
Visual studio compiler bug:
https://developercommunity.visualstudio.com/content/problem/262083/compiler-emits-dynamic-initializer-for-variable-wi.html

Similar bug: https://developercommunity.visualstudio.com/content/problem/1044/compiler-emits-dynamic-initializer-for-constexpr-v.html

The compiler generates dynamic-initialization code for global std::once_flag variables even though the constructor of once_flag is constexpr. As a result, the following code is broken:
https://github.com/google/protobuf/blob/master/src/google/protobuf/descriptor.cc#L1343-L1362

GOOGLE_PROTOBUF_DECLARE_ONCE(generated_pool_init_);
static void InitGeneratedPool() {
  generated_database_ = new EncodedDescriptorDatabase;
  generated_pool_ = new DescriptorPool(generated_database_);
  generated_pool_->InternalSetLazilyBuildDependencies();
}
void InitGeneratedPoolOnce() {
  ::google::protobuf::GoogleOnceInit(&generated_pool_init_, &InitGeneratedPool);
}

InitGeneratedPoolOnce() is called before generated_pool_init_ is dynamically initialized. It will call InitGeneratedPool() and create EncodeDescriptorDatabase/DescriptorPool for the first time.
dynamical initialization of generated_pool_init_ happens and it simply zeros the variable's content.
InitGeneratedPoolOnce() is called again and it calls InitGeneratedPool() again which creates new EncodedDescriptorDatabase/DescriptorPool for the second time.

Anything registered with the descriptordatabase/pool created in (1) will get lost after (3), and as a result descriptors that should already be in the global pool appear missing and this triggers the following check failure:
https://github.com/google/protobuf/blob/master/src/google/protobuf/generated_message_reflection.cc#L2370-L2372

  const ::google::protobuf::FileDescriptor* file =
      ::google::protobuf::DescriptorPool::generated_pool()->FindFileByName(filename);
  GOOGLE_CHECK(file != NULL);

We can workaround the problem by moving the global once_flag into a static variable inside the init function:

void InitGeneratedPoolOnce() {
  static ::google::protobuf::ProtobufOnceType generated_pool_init_;
  ::google::protobuf::GoogleOnceInit(&generated_pool_init_, &InitGeneratedPool);
}

This way, the variable is guaranteed to be initialized before GoogleOnceInit() and it appears to work with Visual Studio 2017.

The text was updated successfully, but these errors were encountered:

xfxyjwf · 2018-06-16T23:23:05Z

See b/110301009

nikhilpothuru · 2018-06-22T00:54:20Z

Hi, This is my first time trying to contribute to an open source project. I am looking to help out with any C++ or Python issues. It would be great to get some help starting off. I've gone through the Developer Guide and Protocol Buffer Basics: C++ to prepare. Thanks!

xfxyjwf · 2018-06-22T01:18:27Z

@nikhilpothuru Thanks for offering help! This issue here is probably not a great place to start though. I think it's probably better to start with some simple cleanups to get yourself more familiar with the protobuf build/development environment.

nikhilpothuru · 2018-06-22T01:41:23Z

Hi! Thank you for the quick reply. Is there a specific cleanup issue you can point me to? I'm looking through the issues, but it is a bit overwhelming since I don't know where to start. Thanks!

remoe · 2018-06-22T11:58:23Z

I've tested with VS 2017 (15.7.4) DEBUG and protobuf 3.6.0:

cmake parameters: -GVisual Studio 15 Win64 -DCMAKE_SYSTEM_VERSION=8.1 -DBUILD_SHARED_LIBS=ON

The protoc executable crashes on tests:

   8>Done Building Project "D:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\_build\test_plugin.vcxproj" (default targets).
    14>d:\apps\vs2017\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code 3. [D:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\
       _build\lite-arena-test.vcxproj]
    14>Done Building Project "D:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\_build\lite-arena-test.vcxproj" (default targets) -- FAILED.
     9>d:\apps\vs2017\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code 3. [D:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\
       _build\tests.vcxproj]
     9>Done Building Project "D:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\_build\tests.vcxproj" (default targets) -- FAILED.
     3>Project "D:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\_build\ALL_BUILD.vcxproj" (3) is building "D:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\_build\lite
       -test.vcxproj" (6) on node 1 (default targets).
     6>InitializeBuildStatus:
         Touching "lite-test.dir\Debug\lite-test.tlog\unsuccessfulbuild".
       CustomBuild:
         Generating D:/sdk/_build/win_x86_64/protobuf-3.6.0-debug/protobuf.git/src/google/protobuf/map_lite_unittest.pb.cc
         [libprotobuf FATAL d:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\src\google\protobuf\message.cc:346] File appears to be in generated pool but wasn't registered: googl
         e/protobuf/descriptor.proto
     6>d:\apps\vs2017\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code 3. [D:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\
       _build\lite-test.vcxproj]

   8>Done Building Project "D:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\_build\test_plugin.vcxproj" (default targets).
    14>d:\apps\vs2017\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code 3. [D:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\
       _build\lite-arena-test.vcxproj]
    14>Done Building Project "D:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\_build\lite-arena-test.vcxproj" (default targets) -- FAILED.
     9>d:\apps\vs2017\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code 3. [D:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\
       _build\tests.vcxproj]
     9>Done Building Project "D:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\_build\tests.vcxproj" (default targets) -- FAILED.
     3>Project "D:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\_build\ALL_BUILD.vcxproj" (3) is building "D:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\_build\lite
       -test.vcxproj" (6) on node 1 (default targets).
     6>InitializeBuildStatus:
         Touching "lite-test.dir\Debug\lite-test.tlog\unsuccessfulbuild".
       CustomBuild:
         Generating D:/sdk/_build/win_x86_64/protobuf-3.6.0-debug/protobuf.git/src/google/protobuf/map_lite_unittest.pb.cc
         [libprotobuf FATAL d:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\src\google\protobuf\message.cc:346] File appears to be in generated pool but wasn't registered: googl
         e/protobuf/descriptor.proto
     6>d:\apps\vs2017\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(171,5): error MSB6006: "cmd.exe" exited with code 3. [D:\sdk\_build\win_x86_64\protobuf-3.6.0-debug\protobuf.git\
       _build\lite-test.vcxproj]

Renshk · 2018-06-27T02:00:47Z

This way, the initialization of generated_pool_init_ is not thread-safe in the InitGeneratedPoolOnce function.

Renshk · 2018-06-27T03:30:22Z

GeneratedMessageFactory::singleton function have the same issue.

xfxyjwf · 2018-06-27T18:10:49Z

@Renshk Why is it not thread-safe? I'm pretty sure C++11 guarantees static local variable to be initialized thread-safely.

wheezil · 2018-06-27T20:32:20Z

Greetings... I ran into this error (well, actually #4679) trying to build protobuf libraries for Windows using VS2017. I found that copying the win32 distribution of protoc.exe over the built one allowed the build to complete successfully. However, nmake check tests fail with similar errors.

Given that I have VS2017 and would like to proceed with a project, what is the best advice for working around the problem, until either VS2017 or protobuf arrives at a solution?

EDIT: does going the vcpkg install route avoid this entirely? Is it an issue with generated code or only with the library build?

Thanks
john

xfxyjwf · 2018-06-27T21:33:44Z

@wheezil The bug only happens in debug build so you can workaround it by using the release build version of protobuf. The pre-built binaries published by us also do not have this problem because they are release builds.

wheezil · 2018-06-27T21:49:45Z

Thanks! I will just go with the pre-built binaries.

@gerben-s

It appears that Visual Studio does not work well with std::once_flag because it has a bug causing it to initialize that during dynamic initialization instead of constant initialization. This change works around the problem by using function static initializers instead. @gerben-s originally wrote this change for the Google-internal codebase but I am just cherry-picking it here. This fixes protocolbuffers#4773.

Today was not a good day. The Windows build broke over the weekend (maybe late last week, but I did not notice until the weekend). This morning I could not even troubleshoot the problem because `strawberryperl.com` was down, and we use that (indirectly) to build openssl on Windows: microsoft/vcpkg#3973 I tried to do other stuff, without success. Late in the morning the site was back up. At first, I thought it was just a matter of adapting to the newer protobuf (3.6.0) that we got as part of a regular vcpkg update: microsoft/vcpkg@c95b6bf Well, the changes I made in our `cmake/*` files (included in this PR) did fix the build, and look like useful changes. But then the unit tests would not pass because of: protocolbuffers/protobuf#4773 Which is "Not Good"[tm]. I decided to revert the vcpkg version for now, that got the tests to compile and pass on my Windows machine. The programming gods wanted to toy with this mortal today. Because the `.appveyor.yml` file was not properly clearing the cache, and the builds on appveyor.com still used the protobuf 3.6 artifacts already cached there. BTW, this is probably why the builds did not break immediately: vcpkg reused the cached versions even other stuff had changed. Our builds continued to work after that commit made it through. I think all the necessary changes are in now. I will commute home and fix anything else that is broken when I get there. May the programming gods be kind to you, oh faithful reviewer. * Use targets in add_custom_command. CMake automatically expands targets to the correct generator expression in add_custom_command, no need for generator expressions. * Set missing paths for PROTOBUF_IMPORT_DIRS. Depending on your version of CMake you get PROTOBUF_IMPORT_DIRS, or Protobuf_IMPORT_DIRS, or nothing: https://cmake.org/cmake/help/v3.10/module/FindProtobuf.html https://cmake.org/cmake/help/v3.5/module/FindProtobuf.html Make an educated guess in the file dealing with such nonsense. * Pin vcpkg to an older version. The newer version includes protobuf-3.6.0 which is broken on Windows.

xfxyjwf added bug c++ labels Jun 16, 2018

xfxyjwf self-assigned this Jun 16, 2018

xfxyjwf mentioned this issue Jun 16, 2018

Google_protobuf failed to build with debug configuration #4409

Closed

xfxyjwf mentioned this issue Jun 22, 2018

The debug version of an error #4679

Closed

xfxyjwf assigned gerben-s and unassigned xfxyjwf Jun 25, 2018

sigiesec mentioned this issue Jul 6, 2018

Assertion error in protoc.exe built by VS2017: CHECK failed: file != NULL #4874

Closed

This was referenced Jul 6, 2018

Fix initialization with Visual Studio #4878

Merged

Merge 3.6.x into master #4882

Merged

acozzette closed this as completed in #4882 Jul 9, 2018

xfxyjwf mentioned this issue Jul 21, 2018

Calling google::protobuf::ShutdownProtobufLibrary() against a DLL build throws an Access violation reading location 0xFFFFFFFFFFFFFFFF exception #4950

Closed

IvanPizhenko mentioned this issue Jul 25, 2018

Protobuf 3.6 build failure with MSVC2017 #4963

Closed

coryan mentioned this issue Jul 30, 2018

URGENT: Fix windows builds googleapis/google-cloud-cpp#947

Merged

Kwizatz mentioned this issue Aug 1, 2018

Protobuf needs to be updated from 3.6.0.1 to 3.6.1 microsoft/vcpkg#3997

Closed

google-admin unassigned gerben-s Aug 21, 2018

xfxyjwf assigned gerben-s Aug 24, 2018

meteorcloudy mentioned this issue Sep 3, 2018

Unable to execute Bazel binary built on Windows bazelbuild/bazel#6053

Closed

alex4814 mentioned this issue Sep 30, 2018

Calling T::descriptor() fails on Debug but works on Release in v3.6.1 #5204

Closed

snnn mentioned this issue Nov 14, 2019

Fix windows conda build onnx/onnx#2452

Merged

vibhoraggarwal mentioned this issue Jun 19, 2020

version 3.3.0 -test failed 1-CommandLineInterfaceTest.W32ErrorMessage #3293

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

global std::once_flag variables don't work with Visual Studio #4773

global std::once_flag variables don't work with Visual Studio #4773

xfxyjwf commented Jun 16, 2018

xfxyjwf commented Jun 16, 2018

nikhilpothuru commented Jun 22, 2018

xfxyjwf commented Jun 22, 2018

nikhilpothuru commented Jun 22, 2018

remoe commented Jun 22, 2018 •

edited

Loading

Renshk commented Jun 27, 2018

Renshk commented Jun 27, 2018

xfxyjwf commented Jun 27, 2018

wheezil commented Jun 27, 2018 •

edited

Loading

xfxyjwf commented Jun 27, 2018

wheezil commented Jun 27, 2018

global std::once_flag variables don't work with Visual Studio #4773

global std::once_flag variables don't work with Visual Studio #4773

Comments

xfxyjwf commented Jun 16, 2018

xfxyjwf commented Jun 16, 2018

nikhilpothuru commented Jun 22, 2018

xfxyjwf commented Jun 22, 2018

nikhilpothuru commented Jun 22, 2018

remoe commented Jun 22, 2018 • edited Loading

Renshk commented Jun 27, 2018

Renshk commented Jun 27, 2018

xfxyjwf commented Jun 27, 2018

wheezil commented Jun 27, 2018 • edited Loading

xfxyjwf commented Jun 27, 2018

wheezil commented Jun 27, 2018

remoe commented Jun 22, 2018 •

edited

Loading

wheezil commented Jun 27, 2018 •

edited

Loading