背景
其他团队二次开发的ffmpeg, 我们要在这个ffmpeg上做一些post action. 比如截图后上传s3,写kafka等等.代码移植后发现崩在kafka库里, 具体位置是在调用crc32.如下:
排查过程
1、崩在库函数中, 怀疑是环境问题? 后来写一个小demo, 发现单独调用kafka功能正常.排除环境问题.
2、gdb 查看crc32地址:
gdb中执行info files 查看内存地址信息:
libz的lib函数地址如下:
gdb 中info files,发现crc32函数地址, 不在libz中, 正常预期的是crc32是在libz库中包含的. 另外gdb中b crc32 发现有两个breakpoint. 分别是libz中的crc32 和第三方团队lib的crc32, 此时已经发现是调用到了第三方团队的crc32. 分析现在的编译和调用模型:
发现编译的时候, librdkafka.a使用的是libz.so的crc32, 但是编译成ffmpeg二进制之后, librdkafka.a 直接调用的就是已经包含在ffmpeg中的pre_build.a中的crc32. 发生不符合预期的结果.
解决方案
同步第三方团队发现的问题, 给到我们的信息是这个函数没有必要向外暴露. 建议第三方团队不要把不必要的函数暴露出来.
反思
这个应该是第三方团队头文件引用关系错乱, 导致对外暴露内部函数导致的问题. 头文件的引用关系, 应该在代码设计的时候确定好内部函数和外部函数.
gdb查看函数内存地址在这次排查中起到很重要的作用.