My guess is that in the target process, the symbol table entry for the specific function (
i.e. google::protobuf::SimpleDescriptorDatabase::DescriptorIndex<std::__1::pair<void const*, int> >::AddFile) was already filled with the statically linked version, then the caching would prevent the binder from looking for the symbol from dylib.Here is an article about dyld, for your information:
Regards,
jz
At 2014-03-20 05:09:22,"Rick Mann" <email@hidden> wrote:
>We've run into an issue where the App Store version of our app crashes on certain devices. Based on the crash logs, Apple's libProtobuf.dylib is getting confused and calling into our statically-linked copy:
>
>Thread 4 Crashed:
>0 libc++.1.dylib 0x3b35e2b5 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 5
>1 MatterScan 0x001e6961 google::protobuf::SimpleDescriptorDatabase::DescriptorIndex<std::__1::pair<void const*, int> >::AddFile(google::protobuf::FileDescriptorProto const&, std::__1::pair<void const*, int>) + 45
>2 libprotobuf.dylib 0x3bbed247 google::protobuf::EncodedDescriptorDatabase::Add(void const*, int) + 127
>3 libprotobuf.dylib 0x3bbcd3cd google::protobuf::DescriptorPool::InternalAddGeneratedFile(void const*, int) + 73
>4 libprotobuf.dylib 0x3bbf2967 google::protobuf::protobuf_AddDesc_google_2fprotobuf_2fdescriptor_2eproto() + 143
>5 libprotobuf.dylib 0x3bc0657d _GLOBAL__I_a + 5
>6 dyld 0x2be6c59f ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 175
>7 dyld 0x2be6c6ad ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 17
>...
>
>Others have experienced this, too:
>
>http://stackoverflow.com/questions/19848118/weird-ios-libprotobuf-dylib-cause-crash
>
>What I'd like to know is this. How can this happen? We statically link in our own build of protobufs. My naive speculation is that when the linker links our binary, it resolves all our call sites then. Since we're not building a dylib, there shouldn't be any machinery needed to link to it.
>
>Now, at run time, it seems that the loader is resolving links from Apple's libProtobuf.dylib BACK INTO our code.
>
>Anyway, this only happens on the newest devices; on older ones, it's fine. So, the version of protobuf on those doesn't result in the same behavior.
>
>I see two workarounds: change the namespace of our version of Protobufs, or suppress the export of all the symbols (we do seem to have a lot exported). I'd rather do the latter, but I'd sure like an expert to weigh in. Thanks!
>
>--
>Rick
>
>
>