Fix initialization with Visual Studio

[acozzette]

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 #4773.

[MartinRe63]

Cool Change. I'm waiting for this.

[jtattermusch]

CC @jtattermusch (we will need a new patch release after this gets merged to be able to bump grpc's third_party/protobuf).

[jtattermusch]

Thanks for the fix! I've verified that the gRPC windows build works fine after applying this patch. When should we expect the v3.6.1 version to be tagged?

[acozzette]

@TeBoring Do you have any other fixes you want to include in the 3.6.1 release? If not then I can take the v3.6.1 version tomorrow and start working on that patch release.

[TeBoring]

I am working on the php change to support php7.3. I can finish it tomorrow.

…

On Tue, Jul 10, 2018 at 18:03 Adam Cozzette ***@***.***> wrote: @TeBoring <https://github.com/TeBoring> Do you have any other fixes you want to include in the 3.6.1 release? If not then I can take the v3.6.1 version tomorrow and start working on that patch release. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4878 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE9H5WRjAanaDyzKeyUyW5wR3ciS8KJ9ks5uFU7sgaJpZM4VGHOn> .

[kingofthebongo2008]

Hey, can you make a tag with the commits so far, say 3.6.0.2
I want to put this into to tensorflow codebase.
Tensorflow on windows does not compile with Visual Studio 2017 due to protobuf asserting. This fixes the issue. Thanks

[acozzette]

I'm working on the 3.6.1 release now and so there will soon be a v3.6.1 tag with this fix.

[pitrou]

I'm suspecting this change is triggering a regression where importing tensorflow before or after pyarrow segfaults: see https://issues.apache.org/jira/browse/ARROW-3466

The traceback we're getting is the following (truncated):

#0  __GI___pthread_mutex_lock (mutex=0x18) at ../nptl/pthread_mutex_lock.c:65
#1  0x00007fffb8a867a5 in google::protobuf::internal::OnShutdownRun(void (*)(void const*), void const*) ()
   from /home/antoine/miniconda3/envs/ttt/lib/python3.6/site-packages/google/protobuf/pyext/../../../../../libprotobuf.so.17
#2  0x00007fffb8a98d79 in google::protobuf::internal::InitProtobufDefaults() ()
   from /home/antoine/miniconda3/envs/ttt/lib/python3.6/site-packages/google/protobuf/pyext/../../../../../libprotobuf.so.17
#3  0x00007fffb8a98f8f in google::protobuf::internal::InitSCCImpl(google::protobuf::internal::SCCInfoBase*) ()
   from /home/antoine/miniconda3/envs/ttt/lib/python3.6/site-packages/google/protobuf/pyext/../../../../../libprotobuf.so.17
#4  0x00007fffb8aab819 in protobuf_google_2fprotobuf_2fany_2eproto::AddDescriptorsImpl() ()
   from /home/antoine/miniconda3/envs/ttt/lib/python3.6/site-packages/google/protobuf/pyext/../../../../../libprotobuf.so.17
#5  0x00007ffff7688827 in __pthread_once_slow (once_control=0x7fffb8e3dcf8 <protobuf_google_2fprotobuf_2fany_2eproto::AddDescriptors()::once>, 
    init_routine=0x7fffc2fdffe1 <std::__once_proxy()>) at pthread_once.c:116
#6  0x00007fffb8aac472 in void std::call_once<void (&)()>(std::once_flag&, void (&)()) ()
   from /home/antoine/miniconda3/envs/ttt/lib/python3.6/site-packages/google/protobuf/pyext/../../../../../libprotobuf.so.17
#7  0x00007ffff7de5733 in call_init (env=0x69c590, argv=0x7fffffffd9f8, argc=3, l=<optimized out>) at dl-init.c:72
#8  _dl_init (main_map=main_map@entry=0xf168c0, argc=3, argv=0x7fffffffd9f8, env=0x69c590) at dl-init.c:119
#9  0x00007ffff7dea1ff in dl_open_worker (a=a@entry=0x7fffffff4e50) at dl-open.c:522
#10 0x00007ffff6a422df in __GI__dl_catch_exception (exception=0x7fffffff4e30, operate=0x7ffff7de9dc0 <dl_open_worker>, args=0x7fffffff4e50)
    at dl-error-skeleton.c:196
#11 0x00007ffff7de97ca in _dl_open (
    file=0x7fffb9321eb0 "/home/antoine/miniconda3/envs/ttt/lib/python3.6/site-packages/google/protobuf/pyext/_message.cpython-36m-x86_64-linux-gnu.so", 
    mode=-2147483646, caller_dlopen=0x7ffff7a51191 <_PyImport_FindSharedFuncptr+417>, nsid=<optimized out>, argc=3, argv=<optimized out>, env=0x69c590)
    at dl-open.c:605
#12 0x00007ffff7475f96 in dlopen_doit (a=a@entry=0x7fffffff5080) at dlopen.c:66
#13 0x00007ffff6a422df in __GI__dl_catch_exception (exception=exception@entry=0x7fffffff5020, operate=0x7ffff7475f40 <dlopen_doit>, args=0x7fffffff5080)
    at dl-error-skeleton.c:196
#14 0x00007ffff6a4236f in __GI__dl_catch_error (objname=0x6960b0, errstring=0x6960b8, mallocedp=0x6960a8, operate=<optimized out>, args=<optimized out>)
    at dl-error-skeleton.c:215
#15 0x00007ffff7476735 in _dlerror_run (operate=operate@entry=0x7ffff7475f40 <dlopen_doit>, args=args@entry=0x7fffffff5080) at dlerror.c:162
#16 0x00007ffff7476051 in __dlopen (
    file=file@entry=0x7fffb9321eb0 "/home/antoine/miniconda3/envs/ttt/lib/python3.6/site-packages/google/protobuf/pyext/_message.cpython-36m-x86_64-linux-gnu.so", mode=<optimized out>) at dlopen.c:87
#17 0x00007ffff7a51191 in _PyImport_FindSharedFuncptr (prefix=prefix@entry=0x7ffff7ada746 "PyInit", 
    shortname=shortname@entry=0x7fffb92b8080 "_message", 
    pathname=pathname@entry=0x7fffb9321eb0 "/home/antoine/miniconda3/envs/ttt/lib/python3.6/site-packages/google/protobuf/pyext/_message.cpython-36m-x86_64-linux-gnu.so", fp=fp@entry=0x0) at ./Python/dynload_shlib.c:95
#18 0x00007ffff7a230bf in _PyImport_LoadDynamicModuleWithSpec (spec=spec@entry=0x7fffb92afac8, fp=fp@entry=0x0) at ./Python/importdl.c:129

I'm honestly not sure what to do with this. Could it be a build issue on our side? Should I open a bug for this?

[pitrou]

Ok, it was an issue on our side. We link protobuf statically through liborc, and some symbols were leaking because of a bug in our version script (see apache/arrow#2731), which got us crashing when libprotobuf.so is then loaded dynamically by tensorflow.