Native异常：signal 11 (SIGSEGV) , code 1 (SEGV_MAPERR), fault addr 0xdeadcab1：

[kangzongzhan]

线上环境有一定概率出来这个问题，看起来是空指针，野指针的问题，具体的堆栈为：

0	#00 pc 000000000001ac5c /xxx/libapkpatch.so
1	#01 pc 000000000001ac7c /xxx/libapkpatch.so
2	#02 pc 000000000001ac48 /xxx/libapkpatch.so
3	#03 pc 000000000001a268 /xxx/libapkpatch.so
4	#04 pc 000000000001a0ec /xxx/libapkpatch.so
5	#05 pc 000000000001a09c /xxx/libapkpatch.so
6	#06 pc 0000000000012ec8 /xxx/libapkpatch.so
7	#07 pc 000000000001451c /xxx/libapkpatch.so
8	#08 pc 00000000000144a0 /xxx/libapkpatch.so
9	#09 pc 0000000000018404 /xxx/libapkpatch.so
10	#10 pc 0000000000015fa8 /xxx/libapkpatch.so
11	#11 pc 0000000000016424 /xxx/libapkpatch.so
12	#12 pc 00000000000074ac /xxx/libapkpatch.so (Java_com_github_sisong_ApkPatch_patch+208)

@sisong 请问遇到过这个问题吗？或者能查到原因吗？

[sisong]

我们没有遇到过这个问题；
提供的相关信息太少了，很难分析；
.so文件使用的我提供的吗，是否自己有修改？
有相关log或者能够重现吗？下载下来的补丁文件有校验吗？ 线上用户遇到的概率有多大？

[kangzongzhan]

.so文件是用的v1.3.6中的so，没有做过修改；
补丁文件和原文件都是md5校验之后再做的patch；
概率估算应该是万分之一，我们灰度发现了20个线上crash便停止了灰度；
我本地没能重现，问题描述中的堆栈是64位so的异常堆栈，找不到更多有用的日志了。 @sisong 能帮忙通过指令地址看看问题具体出现在什么方法上吗？

[sisong]

使用了多线程patch吗?

假设真的是内存问题,可以考虑这样的测试方式:

1. 用addr2line尝试找出源代码位置(估计不行,so文件移除了debug信息);
2. 用linux下的valgrind来测试打补丁过程,从而发现可能的内存访问漏洞;
3. 使用安卓的Address Sanitizer等来进行检测;
4. 方便给我old.apk和补丁文件吗? 以便更好的进行上面的测试 (邮箱: housisong@hotmail.com )

[sisong]

我尝试了linux的valgrind和安卓的Address Sanitizer，都没有发现代码的内存访问问题；
可能需要你提供的用例来测试是否能重现问题了。

[kangzongzhan]

oldApkPath: 存放在/data/data/xxx/files 目录下；
patchFilePath： diff文件是用File.createTempFile存放的；
outNewApkPath: 设置的是/data/data/xxx/files 目录下的文件
tempUncompressFilePath： 设置的是/data/data/xxx/cache下的文件
threadNum：设置固定值4，是多线程patch

@sisong 这里的参数哪里可能有什么隐患吗？我可以尝试改一下再灰度一下；

[sisong]

看异常信息，在执行一个delete[]时访问数组超界，建议升级到v1.3.7（并开启so的symbol）看看。
目录的权限问题也有可能，建议所有文件都放到getApplicationContext().getFilesDir().getPath()或其子目录路径。

[sisong]

开启多线程后又无数据需要压缩，造成提前释放从而引发crash