Details
-
Task
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
As it turned out, there are conflicts during static initialization of symbols related to protobuf extensions in Impala which is dynamically linked against libkudu_client while statically linking in libprotobuf on itself. It seems the issue might be caused by the static initialization of the descriptor pools for protobuf types, so eventually impala complains about that in run-time:
[libprotobuf ERROR google/protobuf/descriptor.cc:3620] Invalid proto descriptor for file "kudu/rpc/rpc_header.proto": [libprotobuf ERROR google/protobuf/descriptor.cc:3623] kudu.rpc.track_rpc_result: ".google.protobuf.MethodOptions" is not defined. [libprotobuf ERROR google/protobuf/descriptor.cc:3623] kudu.rpc.authz_method: ".google.protobuf.MethodOptions" is not defined. [libprotobuf ERROR google/protobuf/descriptor.cc:3623] kudu.rpc.default_authz_method: ".google.protobuf.ServiceOptions" is not defined.
From examining the libkudu_client, it turns out some related protobuf symbols are discoverable:
$ nm -g libkudu_client.so | grep protobuf | grep desc 00000000006469a0 R _ZN50TableStruct_google_2fprotobuf_2fdescriptor_2eproto7offseftsE 0000000000751a20 D descriptor_table_google_2fprotobuf_2fany_2eproto 0000000000751580 D descriptor_table_google_2fprotobuf_2fdescriptor_2eproto 0000000000751ac0 D descriptor_table_google_2fprotobuf_2fsource_5fcontext_2eproto0000000000751b60 D descriptor_table_google_2fprotobuf_2ftype_2eproto 0000000000751cc0 D descriptor_table_google_2fprotobuf_2fwrappers_2eproto 0000000000751900 D scc_info_DescriptorProto_ExtensionRange_google_2fprotobuf_2fdescriptor_2eproto 00000000007519f0 D scc_info_DescriptorProto_ReservedRange_google_2fprotobuf_2fdescriptor_2eproto 0000000000751920 D scc_info_DescriptorProto_google_2fprotobuf_2fdescriptor_2eproto 00000000007519d0 D scc_info_EnumDescriptorProto_EnumReservedRange_google_2fprotobuf_2fdescriptor_2eproto 00000000007518c0 D scc_info_EnumDescriptorProto_google_2fprotobuf_2fdescriptor_2eproto 00000000007518a0 D scc_info_EnumOptions_google_2fprotobuf_2fdescriptor_2eproto 0000000000751880 D scc_info_EnumValueDescriptorProto_google_2fprotobuf_2fdescriptor_2eproto 0000000000751860 D scc_info_EnumValueOptions_google_2fprotobuf_2fdescriptor_2eproto 0000000000751840 D scc_info_ExtensionRangeOptions_google_2fprotobuf_2fdescriptor_2eproto 0000000000751820 D scc_info_FieldDescriptorProto_google_2fprotobuf_2fdescriptor_2eproto 0000000000751800 D scc_info_FieldOptions_google_2fprotobuf_2fdescriptor_2eproto 00000000007517a0 D scc_info_FileDescriptorProto_google_2fprotobuf_2fdescriptor_2eproto 0000000000751780 D scc_info_FileDescriptorSet_google_2fprotobuf_2fdescriptor_2eproto 0000000000751760 D scc_info_FileOptions_google_2fprotobuf_2fdescriptor_2eproto 00000000007519b0 D scc_info_GeneratedCodeInfo_Annotation_google_2fprotobuf_2fdescriptor_2eproto 0000000000751740 D scc_info_GeneratedCodeInfo_google_2fprotobuf_2fdescriptor_2eproto 0000000000751720 D scc_info_MessageOptions_google_2fprotobuf_2fdescriptor_2eproto 0000000000751700 D scc_info_MethodDescriptorProto_google_2fprotobuf_2fdescriptor_2eproto 00000000007516e0 D scc_info_MethodOptions_google_2fprotobuf_2fdescriptor_2eproto 00000000007516c0 D scc_info_OneofDescriptorProto_google_2fprotobuf_2fdescriptor_2eproto 00000000007516a0 D scc_info_OneofOptions_google_2fprotobuf_2fdescriptor_2eproto 0000000000751660 D scc_info_ServiceDescriptorProto_google_2fprotobuf_2fdescriptor_2eproto 0000000000751640 D scc_info_ServiceOptions_google_2fprotobuf_2fdescriptor_2eproto 0000000000751990 D scc_info_SourceCodeInfo_Location_google_2fprotobuf_2fdescriptor_2eproto 0000000000751620 D scc_info_SourceCodeInfo_google_2fprotobuf_2fdescriptor_2eproto 0000000000751970 D scc_info_UninterpretedOption_NamePart_google_2fprotobuf_2fdescriptor_2eproto 0000000000751600 D scc_info_UninterpretedOption_google_2fprotobuf_2fdescriptor_2eproto
The libprotobuf which is statically linked in by impalad doesn't contain any types requiring protobuf extension types, so google.protobuf.MethodOptions and other related types are not registered in the descriptor pool that impalad uses, but libkudu_client needs those. The theory is that libkudu_client, being dynamically linked into impalad, doesn't run static initializers for those extension-related types since it assumes that the descriptor pool created by statically linked in libkudu_client already ran those (though I'm not sure that's exactly what happens there). Probably, we could address that by hiding protobuf symbols exposed from impalad to avoid confusing the static initializers for libkudu_client. However, similar problem might happen with any other Kudu application, and it's easier to rather address that from libkudu_client side than requiring hiding protobuf symbols from all applications trying to link in libkudu_client. So, hopefully the issue might be addressed by hiding libprotobuf symbols in libkudu_client itself.
I found this article which seems to be relevant: https://stackoverflow.com/questions/2222162/how-to-apply-fvisibility-option-to-symbols-in-static-libraries