本文介绍了奇怪的iOS libprotobuf.dylib导致崩溃的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在项目中编译了自己的protobuf(在主要目标中,不是lib),但是我发现崩溃是由于libprotobuf.dylib中的protobuf代码引起的(我猜这是new中新包含的lib)版本的设备-我的设备是ipad air).

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

我猜内部lib ImageLoader会按需加载protobuf,这会覆盖我自己的符号.所以我想知道有什么方法可以使事情做对吗?

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?

推荐答案

是的,较新设备(iPhone 5S和显然是iPad air)上的ImageLoader具有其自己的协议缓冲区副本,该协议缓冲区会导致符号冲突.

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

我通过编辑google/protobuf/stubs/common.h并在文件顶部附近插入以下行来解决此问题:

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

现在,我的Google protobuf实现副本使用名称空间"myapp"而不是"google",因此这些符号不会与系统符号冲突.

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.

这篇关于奇怪的iOS libprotobuf.dylib导致崩溃的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-11 02:28