weird ios libprotobuf.dylib cause crash

Question

i have my own protobuf compiled in the project (in the main target, not a lib), but I found a crash which is caused by protobuf code in libprotobuf.dylib ( which in my guess is a newly included lib in new version of device -- mine is ipad air).

* thread #1: tid = 0x6598, 0x0027e96e TutorChat`void google::protobuf::internal::RepeatedPtrFieldBase::Destroy<google::protobuf::RepeatedPtrField<google::protobuf::UninterpretedOption>::TypeHandler>(this=0x1567158c) + 66 at repeated_field.h:814, queue = 'com.apple.main-thread, stop reason = breakpoint 2.41
    frame #0: 0x0027e96e TutorChat`void google::protobuf::internal::RepeatedPtrFieldBase::Destroy<google::protobuf::RepeatedPtrField<google::protobuf::UninterpretedOption>::TypeHandler>(this=0x1567158c) + 66 at repeated_field.h:814
    frame #1: 0x37f231f2 libprotobuf.dylib`google::protobuf::FileOptions::~FileOptions() + 38
    frame #2: 0x37f231be libprotobuf.dylib`google::protobuf::FileOptions::~FileOptions() + 10
    frame #3: 0x37f18764 libprotobuf.dylib`google::protobuf::FileDescriptorProto::~FileDescriptorProto() + 56
    frame #4: 0x37f11296 libprotobuf.dylib`google::protobuf::EncodedDescriptorDatabase::Add(void const*, int) + 206
    frame #5: 0x37ef13d0 libprotobuf.dylib`google::protobuf::DescriptorPool::InternalAddGeneratedFile(void const*, int) + 76
    frame #6: 0x37f1696a libprotobuf.dylib`google::protobuf::protobuf_AddDesc_google_2fprotobuf_2fdescriptor_2eproto() + 146
    frame #7: 0x37f2a580 libprotobuf.dylib`_GLOBAL__I_a + 8
    frame #8: 0x2be0e5a0 dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 176
    frame #9: 0x2be0e6b0 dyld`ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 20
    frame #10: 0x2be0bd36 dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) + 358
    frame #11: 0x2be0bcb8 dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&) + 232
    frame #12: 0x2be0bb8c dyld`ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 40
    frame #13: 0x2be05276 dyld`dyld::runInitializers(ImageLoader*) + 78
    frame #14: 0x2be092c2 dyld`dlopen + 1030
    frame #15: 0x381d978c libdyld.dylib`dlopen + 48
    frame #16: 0x2f863794 libGFXShared.dylib`gfxInitializeLibrary + 1056
    frame #17: 0x2f7940fc GLEngine`gliInitializeLibrary + 44
    frame #18: 0x2f856b60 OpenGLES`eagl_init + 436
    frame #19: 0x2f856792 OpenGLES`-[EAGLSharegroup initWithAPI:sharedWithCompute:] + 114
    frame #20: 0x2f855b7e OpenGLES`-[EAGLContext initWithAPI:properties:] + 242
    frame #21: 0x0179870e libglInterpose.dylib`EAGLContext_initWithAPIProperties(EAGLContext*, objc_selector*, unsigned int, NSDictionary*) + 74
    frame #22: 0x2f8559de OpenGLES`-[EAGLContext initWithAPI:sharedWithCompute:] + 142

I guess the internal lib ImageLoader loads protobuf as its need, and this overwrites my own symbols. So I am wondering is there any way to make things right?

Answer 1

Yes, ImageLoader on the newer devices (iPhone 5S and apparently iPad air) has its own copy of Protocol Buffers which causes symbol collisions.

I hacked around this by editing my google/protobuf/stubs/common.h and inserting the following line near the top of the file:

#define google myapp

Now, my copy of the Google protobuf implementation uses the namespace "myapp" instead of "google" and so the symbols don't collide with the system ones.

Answer 2

I am experiencing the same issue. Taking a queue from lincolnq I modified my protobuf build script to rename the ::google namespace to ::google_public in my build. This works around the issue with the Apple private build of protobuf.

I have published a script that creates a build of protobuf that will work. You can take a look here:

https://gist.github.com/BennettSmith/7150245

The script will produce a fat binary for the library that works with all architectures. It also builds the protoc compiler so you can run it as a custom build step to compile your .proto files.

Cheers

-- Bennett

Answer 3

I just ran into the problem today. I'm building with Symbols Hidden by Default set to YES (as well as the inline counterpart). After extensive examination with nm -g, this hides the exported Google protobuf symbols Apple seemed to be calling (which are different than the ones you got, but still in the same place; Image loading).

I'll update this answer after Apple approves us and I verify it works.