新浪博客

火焰山其实是猴子自己踢翻的丹炉

2022-07-29 11:02阅读：

http://blog.sina.cn/dpool/blog/u/1093245591

今天项目上遇到一个奇葩的问题
运行程序，报错
(lldb) p (char*)dlerror()
warning: could not execute support code to read Objective-C class data in the process. This may reduce the quality of type information available.
(char *) $0 = 0x0000000147e218c9 'dlopen(/Users/conanchen/client-delivery/Output/MAC64/Release/Fusion360.app/Contents/Libraries/Applications/Fusion/NaFusionUI10.dylib, 0x0001): Symbol not found: __ZTIN8Autodesk16ContentServiceUI10ISearchBoxE Referenced from: /Users/conanchen/client-delivery/Output/MAC64/Release/Libraries/Applications/Fusion/NaFusionUI10.dylib Expected in: /Users/conanchen/client-delivery/Output/MAC64/Release/Frameworks/AIRMAX/libContentService.dylib'
奇怪的是这货竟然可以编译过，怎么可能运行的时候找不到这个Symbol呢，让我怀疑人生，还以为发现了编译器的Bug。
conanchen@ConanChen ~ % c++filt __ZTIN8Autodesk16ContentServiceUI10ISearchBoxE
typeinfo for Autodesk::ContentServiceUI::ISearchBox
这个是个typeinfo。我开始想typeinfo是不是有什么特别。不懂的问题太多的时候，思路就混乱。
想从链接的时候找问题，先需要看看到
底提供了哪些方法，确定一下是不是没有这个symbol。昨天命令没找到。
今天早上，重新运行一下。
conanchen@ConanChen ~ % nm -nm /Users/conanchen/client-delivery/3P/AIRMAX/NU.FY23_2022.07.12/MAC64_universal_rpath/Frameworks/Release/AIRMAX/libContentServiceUI.dylib | grep __ZTIN8Autodesk16ContentServiceUI10ISearchBoxE
0000000000004198 (__DATA_CONST,__const) external __ZTIN8Autodesk16ContentServiceUI10ISearchBoxE
不是明明有吗？
昨天运行的是
conanchen@ConanChen ~ % nm -nm /Users/conanchen/client-delivery/3P/AIRMAX/NU.FY23_2022.07.12/MAC64_universal_rpath/Frameworks/Release/AIRMAX/libContentService.dylib | grep __ZTIN8Autodesk16ContentServiceUI10ISearchBoxE
仔细对一下发现，一个是libContentService另一个是libContentServiceUI。奇怪了，报错说在libContentService里找不到，其实它是在libContentServiceUI里，难道这个也会错？还会跑偏？记录库的序号可能错，偏了1个？
不相信库，就是不相信计算机本身，库错的概率远低于你自己。
(lldb) image list | grep libContentService.dylib
[ 0] 8B48E1B3-5ADD-3981-A5DB-29B10BFD70B6 0x0000000102b5c000 /Users/conanchen/client-delivery/Output/MAC64/Release/Fusion360.app/Contents/Frameworks/AIRMAX/libContentService.dylib
(lldb) image list | grep libContentServiceUI.dylib
error: the target has no matching modules
发现只加载了libContentService 而没有libContentServiceUI。
突然想到会不会是ID有问题，于是
conanchen@ConanChen ~ % otool -D -arch arm64 /Users/conanchen/client-delivery/Output/MAC64/Release/Frameworks/AIRMAX/libContentServiceUI.dylib
/Users/conanchen/client-delivery/Output/MAC64/Release/Frameworks/AIRMAX/libContentServiceUI.dylib:
@rpath/AIRMAX/libContentService.dylib
还果然是它。所以问题在于，编译的时候，它从libContentServiceUI.dylib里找到了方法，但是当生成二进制文件的时候，它不会写物理硬盘上的文件名。而会用它的ID来指向，这个Case很小众，明明是libContentServiceUI，它的ID却是libContentService。所以明明Symbol在B里，它却找的A，同时上面的加载也可以看到，它加载了libContentService而没有加载libContentServiceUI。
而这个ID是怎么产生的呢，是我自己在改Rpath的时候，发现ID也要改，所以拷贝来拷贝去，把B指向了A。始作俑者乃是本人自己。自己坑了自己。给自己弄了个火焰山。

我的更多文章

下载客户端阅读体验更佳

APP专享