Thanks for your insights! It may also gets complicated with the environment I'm testing it in. Hence, I'd like to know when does protobuf invoke this method? Is it just when static variable "static_descriptor_initializer" gets initialized?
Thanks, On Thu, 25 Jul 2019 at 14:19, Adam Cozzette <[email protected]> wrote: > If you can't edit the .proto files then I think the only solution is to > make sure the code for content-meta-info.proto only appears in one dylib > (or in the main binary only). > > I'm not sure I would fully trust nm to report which dylibs are including > the code, because I can imagine that some or all of the symbols could get > stripped depending on how they're built. If the string "ContentMetaInfo" > appears in multiple binaries then they might all be including the generated > code for that .proto file. > > On Thu, Jul 25, 2019 at 2:06 PM Peter Gusev <[email protected]> wrote: > >> Thanks! I think I've seen this kind of solution somewhere online before... >> but what if I don't have any edit access to the .proto files? >> >> In my debugger, I noticed the crash originates in >> >> void AddDescriptors() { >> >> static ::google::protobuf::internal::once_flag once; >> >> ::google::protobuf::internal::call_once(once, AddDescriptorsImpl); >> >> } >> >> So I search all dylibs my plugin uses (and the plugin itself) for this >> symbol (as ' nm <binary> | grep "AddDescriptorsImpl" ') and the only place >> I found this symbol was in one dylib: >> >> 0000000000000f70 T >> __ZN38protobuf_content_2dmeta_2dinfo_2eproto18AddDescriptorsImplEv >> >> 0000000000013fc0 s >> __ZZN38protobuf_content_2dmeta_2dinfo_2eproto18AddDescriptorsImplEvE10descriptor >> I'm trying to understand, how this code might be called twice?... >> However, I can see various "ContentMetaInfo" in three different binaries >> (two dylibs and plugin binary). >> >> On Thu, 25 Jul 2019 at 13:39, Adam Cozzette <[email protected]> wrote: >> >>> Based on the error message I think you have the right diagnosis of the >>> problem. There are a couple ways you could try to fix it: >>> 1. Move the generated protobuf code into its own dylib so that the >>> original two dylibs don't include it themselves. >>> 2. Alternatively, if you don't rely on protobuf reflection then you can >>> set option optimize_for = LITE_RUNTIME; in the .proto file. That will >>> remove reflection support, and as a side effect the generated protos will >>> not register themselves in the process-wide descriptor pool (which is where >>> the crash came from). I think you would still have to be careful to avoid >>> ODR violations, so you might need to carefully set up the dylibs to hide >>> their generated protobuf symbols. >>> >>> On Thu, Jul 25, 2019 at 10:11 AM { peetonn } <[email protected]> wrote: >>> >>>> I'm getting a runtime error: >>>> >>>> *[libprotobuf ERROR google/protobuf/descriptor_database.cc:58] File >>>> already exists in database: content-meta-info.proto* >>>> >>>> *[libprotobuf FATAL google/protobuf/descriptor.cc:1358] CHECK failed: >>>> GeneratedDatabase()->Add(encoded_file_descriptor, size): * >>>> >>>> *libc++abi.dylib: terminating with uncaught exception of type >>>> google::protobuf::FatalException: CHECK failed: >>>> GeneratedDatabase()->Add(encoded_file_descriptor, size): * >>>> >>>> Which, I believe, happens because my macOS plugin code links against >>>> two .dylibs which use protobuf and, apparently, use same protobuf objects. >>>> (Is this assumption correct? How can I check it?) >>>> >>>> How one shall debug and fix this error (given dylibs are third-party)? >>>> >>>> Thanks, >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Protocol Buffers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/protobuf/274860bb-6027-4324-9674-4ac9d21d1ca2%40googlegroups.com >>>> <https://groups.google.com/d/msgid/protobuf/274860bb-6027-4324-9674-4ac9d21d1ca2%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >> >> -- >> Peter Gusev <https://www.linkedin.com/in/peter-gusev-8135441a/> >> gusev.io >> [email protected] >> *+1 213 587-27-48* >> >> >> *Research Scholar @ REMAP UCLA >> <http://www.remap.ucla.edu/home/about>Video >> streaming/ICN networks/Creative Coding/Interactive Media* >> > -- Peter Gusev <https://www.linkedin.com/in/peter-gusev-8135441a/> gusev.io [email protected] *+1 213 587-27-48* *Research Scholar @ REMAP UCLA <http://www.remap.ucla.edu/home/about>Video streaming/ICN networks/Creative Coding/Interactive Media* -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/protobuf/CAMxZbOEFfrWSb5BqRLDsmoJaZhjyy50fYKi%3D%2B5aOO%2BdaZK9Zpg%40mail.gmail.com.
