ncnn模型在Android端跑压力测试时出现signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)导致应用崩溃退出

[bestpower]

最近对人脸特征检测模型跑压力测试时总是出现应用崩溃的情况：
测试情况：对多张人脸图片进行10000次遍历人脸特征提取检测，经常在测试了一两个小时之后出现测试应用崩溃退出的现象，经排查Java层代码并无问题，也非内存不足，主要是在jni层调用ncnn模型推理时出现的异常
ncnn库版本：5月26日下拉ncnn代码到最新编译的版本 （armeabi-v7a）
ndk版本：android-ndk-r19c（用于ncnn库与android应用编译）
android studio版本：3.2
android应用运行设备系统版本：android 7.1.1 API 25
崩溃日志如下：
05-26 22:39:20.742 4657 4676 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 4676 (Thread-4)
05-26 22:39:21.304 4758 4758 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
05-26 22:39:21.308 4758 4758 F DEBUG : Revision: '0'
05-26 22:39:21.308 4758 4758 F DEBUG : ABI: 'arm'
05-26 22:39:21.309 4758 4758 F DEBUG : pid: 4657, tid: 4676, name: Thread-4 >>> com.demo.face <<<
05-26 22:39:21.309 4758 4758 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
05-26 22:39:21.309 4758 4758 F DEBUG : r0 00000000 r1 00000000 r2 00000000 r3 8c9feb54
05-26 22:39:21.309 4758 4758 F DEBUG : r4 00000080 r5 8c9fee70 r6 8c9fee6c r7 a969a650
05-26 22:39:21.309 4758 4758 F DEBUG : r8 32c07078 r9 8d3f5900 sl 8c9fee80 fp 8d3f5900
05-26 22:39:21.309 4758 4758 F DEBUG : ip a9dd3860 sp 8c9feb10 lr 9dd853af pc 9dd853b4 cpsr 800f0030
05-26 22:39:21.346 4758 4758 F DEBUG :
05-26 22:39:21.346 4758 4758 F DEBUG : backtrace:
05-26 22:39:21.348 4758 4758 F DEBUG : #00 pc 0003f3b4 /data/app/com.demo.face-1/lib/arm/libFace.so
05-26 22:39:21.348 4758 4758 F DEBUG : #1 pc 0003f60d /data/app/com.demo.face-1/lib/arm/libFace.so
05-26 22:39:21.348 4758 4758 F DEBUG : #2 pc 0003da67 /data/app/com.demo.face-1/lib/arm/libFace.so (Java_com_tracking_Face_FaceCharacter+322)
05-26 22:39:21.348 4758 4758 F DEBUG : #3 pc 000ae319 /system/lib/libart.so (art_quick_generic_jni_trampoline+40)
05-26 22:39:21.348 4758 4758 F DEBUG : #4 pc 0000078d /dev/ashmem/dalvik-jit-code-cache (deleted)
05-26 22:39:23.105 314 314 W : debuggerd: resuming target 4657
05-26 22:39:23.152 592 592 I Zygote : Process 4657 exited due to signal (11)
05-26 22:39:23.290 1609 2297 I ActivityManager: Process com.demo.face (pid 4657) has died
05-26 22:39:23.290 1609 2297 D ActivityManager: cleanUpApplicationRecord -- 4657
05-26 22:39:23.322 1609 2297 W ActivityManager: Service crashed 2 times, stopping:

麻烦帮忙分析一下到底是什么问题引起的异常？

[bestpower]

目前在jni层调用ncnn模型代码处加异常捕获，压力测试抛出异常应用并不会挂掉，但是在捕获异常后重复执行异常代码仍继续报异常，说明该异常非偶发性，这样的情况是属于什么问题呢？

[yippeesoft]

不用jni，直接exe运行呢

[bestpower]

目前通过崩溃的backtrace提示的pc地址用ndk工具分析发现很多指向到ncnn库中的代码问题：
ncnn::Mat::create(int, int, int, unsigned int, int, ncnn::Allocator*)
ncnn::Padding_arm::forward(ncnn::Mat const&, ncnn::Mat&, ncnn::Option const&) const
ncnn::copy_make_border(ncnn::Mat const&, ncnn::Mat&, int, int, int, int, int, float, ncnn::Option const&)
ncnn::ConvolutionDepthWise::make_padding(ncnn::Mat const&, ncnn::Mat&, ncnn::Option const&) const
ncnn::ConvolutionDepthWise_arm::forward(ncnn::Mat const&, ncnn::Mat&, ncnn::Option const&) const
ncnn::Net::forward_layer(int, std::__ndk1::vector<ncnn::Mat, std::__ndk1::allocatorncnn::Mat >&, ncnn::Option const&) const
libgcc2.c:?

[bestpower]

直接编译benchncnn在安卓设备上模拟压力跑模型是OK的，但是无法真实还原实际情况，目前自行在推理方法中加了一些日志：
ncnn::Extractor ex = Recognet.create_extractor();
ex.set_num_threads(threadnum);
ex.set_light_mode(true);
ex.input("data", img); // input node
ncnn::Mat out;
int status = ex.extract("out", out); // output node
最后输出的status值是-100（IMAGE_ALLOCATION_FAILED），正常应该是0
这样导致输出out的里也是没有数据的
经打印输入节点数据里的信息发现并无异常或缺失，也就是说输入数据是完整的，就是在extract方法内出现了异常，请问该问题一般是什么原因造成的，该如何规避？

[bestpower]

另外在压力测试中extract方法出现异常时除了返回异常值还经常出现直接崩溃的情况，无法通过状态值捕获和异常处理：
Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 13936 (Thread-2)
也就是内存越界
这样非常影响应用体验，能否改进。

[lexuszhi1990]

刚好我也做了人脸landmark，也做过大量的测试，目测这个问题跟ncnn没有关系，应该是你代码代码的原因，输入数据 多线程 内存泄漏 等

[bestpower]

刚好我也做了人脸landmark，也做过大量的测试，目测这个问题跟ncnn没有关系，应该是你代码代码的原因，输入数据 多线程 内存泄漏 等

这样的问题一般通过宏观测试工具很难察觉，这几天通过打印native层的一些堆内存使用信息精确到kb单位发现，在压力测试的情况下NativeHeapAllocatedSize一直在增长且速度较快，跟内存泄漏还是一定有关系的，检查jni代码，将调用推理方法中创建的一些对象在方法结束时逐一清理释放，再进行压测发现NativeHeapAllocatedSize的增长明显慢了许多，一般的压测不会再出现崩溃问题了，但是NativeHeapAllocatedSize只是增长变慢了而已，如果再延长测试时间，还是会有崩溃的风险，目前正在查找原因

[lexuszhi1990]

刚好我也做了人脸landmark，也做过大量的测试，目测这个问题跟ncnn没有关系，应该是你代码代码的原因，输入数据 多线程 内存泄漏 等

这样的问题一般通过宏观测试工具很难察觉，这几天通过打印native层的一些堆内存使用信息精确到kb单位发现，在压力测试的情况下NativeHeapAllocatedSize一直在增长且速度较快，跟内存泄漏还是一定有关系的，检查jni代码，将调用推理方法中创建的一些对象在方法结束时逐一清理释放，再进行压测发现NativeHeapAllocatedSize的增长明显慢了许多，一般的压测不会再出现崩溃问题了，但是NativeHeapAllocatedSize只是增长变慢了而已，如果再延长测试时间，还是会有崩溃的风险，目前正在查找原因

NativeHeapAllocatedSize 应该是某些变量 new 出来以后 没有delete，或者有C++类中的变量重复的new，而在 new之前没有释放等等 这个是个技术活....