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*
--
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/CAMxZbOHE4HPiWQ1z_mfduDy9R%2Bp%2BJ__LqqxZWbw1ckiq2j5VKA%40mail.gmail.com.
