Native异常：signal 11 (SIGSEGV) , code 1 (SEGV_MAPERR), fault addr 0xdeadcab1： about apkdiffpatch HOT 7 CLOSED

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

from apkdiffpatch.

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

from apkdiffpatch.

使用了多线程patch吗?

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

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

from apkdiffpatch.

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

from apkdiffpatch.

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

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

from apkdiffpatch.

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

from apkdiffpatch.

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

from apkdiffpatch.