This makes me think of what could potentially cause this code to execute twice?...
On Thu, 25 Jul 2019 at 16:13, Adam Cozzette <[email protected]> wrote: > Right, this registration will happen when that static variable's > initialization occurs. Ordinarily this will happen pre-main, though if > you're dynamically loading these dylibs then it will happen at that loading > time as well. > > On Thu, Jul 25, 2019 at 4:01 PM Peter Gusev <[email protected]> wrote: > >> 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* >> > -- 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/CAMxZbOESC%2BOURiiRVrwHKkxSfnwW4qO9umAfzepZmEQtEj0O7A%40mail.gmail.com.
