AN 外置字幕CTS crash（memcpy） && backtrac文件分析

报错的backtrace

01-01 20:16:43.110 1687 1687 F DEBUG : backtrace: 01-01 20:16:43.110 1687 1687 F DEBUG : 00 pc 0001692c /system/lib/libc.so (__memcpy_base+88)  01-01 20:16:43.111 1687 1687 F DEBUG : 01 pc 000f854f /system/lib/libmmp.so  01-01 20:16:43.111 1687 1687 F DEBUG : 02 pc 000eadd9 /system/lib/libmmp.so (_ZN7android9MstPlayer15getSubtitleDataEPi+60) 01-01 20:16:43.111 1687 1687 F DEBUG : 03 pc 00047e47 /system/lib/libmediaplayerservice.so (_ZN7android18MediaPlayerService6Client15getSubtitleDataEPi+30) 01-01 20:16:43.111 1687 1687 F DEBUG : 04 pc 000845a5 /system/lib/libmedia.so (_ZN7android13BnMediaPlayer10onTransactEjRKNS_6ParcelEPS1_j+2264) 01-01 20:16:43.111 1687 1687 F DEBUG : 05 pc 000198f1 /system/lib/libbinder.so (_ZN7android7BBinder8transactEjRKNS_6ParcelEPS1_j+60) 01-01 20:16:43.111 1687 1687 F DEBUG : 06 pc 0001ec7b /system/lib/libbinder.so (_ZN7android14IPCThreadState14executeCommandEi+550) 01-01 20:16:43.111 1687 1687 F DEBUG : 07 pc 0001ede5 /system/lib/libbinder.so (_ZN7android14IPCThreadState20getAndExecuteCommandEv+64) 01-01 20:16:43.111 1687 1687 F DEBUG : 08 pc 0001ee49 /system/lib/libbinder.so (_ZN7android14IPCThreadState14joinThreadPoolEb+48) 01-01 20:16:43.111 1687 1687 F DEBUG : 09 pc 0002388d /system/lib/libbinder.so 01-01 20:16:43.111 1687 1687 F DEBUG : 10 pc 00010071 /system/lib/libutils.so (_ZN7android6Thread11_threadLoopEPv+112) 01-01 20:16:43.111 1687 1687 F DEBUG : 11 pc 000415db /system/lib/libc.so (_ZL15__pthread_startPv+30) 01-01 20:16:43.111 1687 1687 F DEBUG : 12 pc 00019235 /system/lib/libc.so (__start_thread+6)

利用arm的命令add2line对含有symbol的so文件分析

在我这里是

\android6.0\out\target\product\mangosteen\obj_arm\SHARED_LIBRARIES\libmmp_intermediates\PACKED

的libmmp.so文件

则add2line -e file PC -f

即add2line -e libmmp.so 000f854f  -f

add2line -e libmmp.so 000eadd9  -f

由此分析得出出错的函数和大致行数

andrew.wang@szbcsvru6401:~/android6.0/out/target/product/mangosteen/obj_arm/SHARED_LIBRARIES/libmmp_intermediates/PACKED$ arm-linux-androideabi-addr2line -e libmmp.so 000eadd9 -f _ZN7android9MstPlayer15getSubtitleDataEPi /net/szswork01/work/andrew.wang/android6.0/device/mstar/common/libraries/media/mmplayer/mmp/platform/mstplayer/mstplayer.cpp:5182 (discriminator 1) andrew.wang@szbcsvru6401:~/android6.0/out/target/product/mangosteen/obj_arm/SHARED_LIBRARIES/libmmp_intermediates/PACKED$ arm-linux-androideabi-addr2line -e libmmp.so 000f854f -f memcpy /net/szswork01/work/andrew.wang/android6.0/bionic/libc/include/string.h:184 (discriminator 1)

最后发现是memcpy(mpStoreTagData, mpDataBuf, *pudata);

的size 为负数，但是因为memcpy的第三个参数实际上是无符号的形参，所以接受到的数很大，导致内存越界了

void *memcpy(void *dest, const void *src,size_t n);

size_t 类型定义在cstddef头文件中，该文件是C标准库的头文件stddef.h的C++版。它是一个与机器相关的unsigned类型，其大小足以保证存储内存中对象的大小。

这里注意，无符号数是不能输出负数的，即使用10进制打印出来是负数，所以不能和0进行比较，要用有符号数才能和0比较。

另外负数打印出16进制，直观上看不出到底是正数还是负数，所以debug的时候用10进制打印比较好看。

if(mpStoreTagData == NULL || mpDataBuf == NULL || mu32CurTagSize <= 0)
    {
        ALOGE("getSubtitleData error!");
        *pudata  = 0;
        return NULL;
    }
    memcpy(mpStoreTagData, mpDataBuf, *pudata);

比如上面的mu32CurTagSize 打印出来时负数但是就是不反回，导致memcpy出错了，后来一看这货是无符号数啊，说明一直比0大或者等于， 怎么可能小于0呢。。无语

好久没看C了...

好弱...