Ncnn: Android的JNI开发,使用两个基于ncnn的本地库时,运行出现 Fatal signal 6 (SIGABRT)错误

Created on 5 May 2019  ·  25Comments  ·  Source: Tencent/ncnn

JNI接口使用两个本地lib,分别编译成动态库mtcnn.so和mfnet.so。两个动态库都基于ncnn,且都链接了libncnn.a的静态库。
运行时,mtcnn功能正常,运行到mfnet时报错。尝试不加载mtcnn时(或者注释掉所有mtcnn的.load_param()方法),mfnet可以跑通,不报错。
另外我发现这并不一定时mfnet的问题,当我把mfnet的所有代码替换为mtcnn时(即mfnet.so和mtcnn.so相同),同样在运行第二个本地库时报错,且错误相同?

请问大神该如何解决?

AS的Logcat报错信息如下:

2017-08-05 19:25:41.912 20274-20274/com.example.dms A/libc: Fatal signal 6 (SIGABRT), code -6 in tid 20274 (com.example.dms), pid 20274 (com.example.dms)
2017-08-05 19:25:41.997 20339-20339/? A/DEBUG: * *
2017-08-05 19:25:41.997 20339-20339/? A/DEBUG: Build fingerprint: 'rockchip/rk3399pro/rk3399pro:8.1.0/OPM8.190305.001/101257:userdebug/test-keys'
2017-08-05 19:25:41.997 20339-20339/? A/DEBUG: Revision: '0'
2017-08-05 19:25:41.997 20339-20339/? A/DEBUG: ABI: 'arm64'
2017-08-05 19:25:41.997 20339-20339/? A/DEBUG: pid: 20274, tid: 20274, name: com.example.dms >>> com.example.dms <<<
2017-08-05 19:25:41.997 20339-20339/? A/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
2017-08-05 19:25:41.997 20339-20339/? A/DEBUG: x0 0000000000000000 x1 0000000000004f32 x2 0000000000000006 x3 0000000000000008
2017-08-05 19:25:41.997 20339-20339/? A/DEBUG: x4 0000007999fd6000 x5 0000007999fd6000 x6 0000007999fd6000 x7 00000000001c7ea0
2017-08-05 19:25:41.997 20339-20339/? A/DEBUG: x8 0000000000000083 x9 0000000010000000 x10 0000007ff69ab5e0 x11 0000000000000001
2017-08-05 19:25:41.997 20339-20339/? A/DEBUG: x12 0000000000000018 x13 00000003e8000000 x14 00364add5e425850 x15 00000f704fc4ba2b
2017-08-05 19:25:41.997 20339-20339/? A/DEBUG: x16 00000059ddea0fa8 x17 000000799688752c x18 00000078fc6e5400 x19 0000000000004f32
2017-08-05 19:25:41.997 20339-20339/? A/DEBUG: x20 0000000000004f32 x21 0000000000000083 x22 00000078fd3f0cea x23 00000079154e11d6
2017-08-05 19:25:41.997 20339-20339/? A/DEBUG: x24 00000078fd3f0cee x25 00000078fd43a000 x26 000000791558964c x27 0000007ff69ab970
2017-08-05 19:25:41.997 20339-20339/? A/DEBUG: x28 000000799a13fa40 x29 0000007ff69ab620 x30 000000799683c760
2017-08-05 19:25:41.997 20339-20339/? A/DEBUG: sp 0000007ff69ab5e0 pc 000000799683c788 pstate 0000000060000000
2017-08-05 19:25:41.999 20339-20339/? A/DEBUG: backtrace:
2017-08-05 19:25:41.999 20339-20339/? A/DEBUG: #00 pc 000000000001d788 /system/lib64/libc.so (abort+120)
2017-08-05 19:25:41.999 20339-20339/? A/DEBUG: #01 pc 000000000015e498 /data/app/com.example.dms-hnU3L7aK-rU0IqLRnkVVkg==/lib/arm64/libmfnet.so (__kmp_abort_process+44)

Most helpful comment

可以参考 https://github.com/android/ndk/issues/1028 的建议,修改 ld flags

老的ndk上尝试

-Wl,-Bstatic -lomp -Wl,-Bdynamic

新的ndk这样


All 25 comments

@nihui 求大神解答,倒腾了一周没进展 ORZ

@nihui 求大神解答,倒腾了一周没进展 ORZ

合一个

@onexuan 两个动态库合并成一个,问题解决了。可能是本地动态库链接的问题,具体原因不知道···

不合并的话试试 strip 两个你的 so,看看能否解决。

请问有没有解决呢?我也遇到类似问题,尝试了自己编译ncnn库,感觉是和openmp有关

请问有没有解决呢?我也遇到类似问题,尝试了自己编译ncnn库,感觉是和openmp有关

我把mtcnn、mfnet和ncnn编译成一个动态库后解决了,具体什么原因还不知道

遇到了同样的问题@_@

同样问题,有什么优雅的解决方案吗?

同样问题,有什么优雅的解决方案吗?

必须分so的话,就不要用.a了,编译一个libncnn.so共用来解决相对优雅一点

你好,请问后面有其他解决方法吗,我被这个bug缠了好几天

可以参考 https://github.com/android/ndk/issues/1028 的建议,修改 ld flags

老的ndk上尝试

-Wl,-Bstatic -lomp -Wl,-Bdynamic

新的ndk这样


@nihui,非常感谢,更新了ndk,加了ldflags果然成功了

@nihui,非常感谢,更新了ndk,加了ldflags果然成功了

你好,这个问题,我也遇到了,然后我使用了ndk r21,在ld flags里用了-fopenmp -static-openmp结果仍然不可用,单独调用也是可以的,麻烦能帮我详细说一下相关的配置么

同样的问题,一个工程包含2个编译so的module(都是使用ncnn的模块) ,单独跑哪个都没问题,2个一起跑就崩了,报错是(__kmp_abort_process+44),链接已经加上了 -fopenmp -static-openmp,还是老样子
按照 @DolbyYu的方式合一起确实好了,但是我需要分发2个so,还是必须得分开,望大神帮忙

同样的问题,一个工程包含2个编译so的module(都是使用ncnn的模块) ,单独跑哪个都没问题,2个一起跑就崩了,报错是(__kmp_abort_process+44),链接已经加上了 -fopenmp -static-openmp,还是老样子
按照 @DolbyYu的方式合一起确实好了,但是我需要分发2个so,还是必须得分开,望大神帮忙

@wangyangneu @zdx3145 生成每个.so库的时候,指定openmp.so的路径来链接openmp的动态库,我是这么解决的,希望可以帮到你。

我也碰到了类似的问题,最后讲两个jni的链接库改成一个。问题解决

如果是静态加载的ncnn.a,需要编译.a的时候就做修改,否则只修改so中的配置还是会报错 @zdx3145

@wangyangneu 请教一下,如何在编译.a的时候修改..

同样的问题,一个工程包含2个编译so的module(都是使用ncnn的模块) ,单独跑哪个都没问题,2个一起跑就崩了,报错是(__kmp_abort_process+44),链接已经加上了 -fopenmp -static-openmp,还是老样子
按照 @DolbyYu的方式合一起确实好了,但是我需要分发2个so,还是必须得分开,望大神帮忙

@wangyangneu @zdx3145 生成每个.so库的时候,指定openmp.so的路径来链接openmp的动态库,我是这么解决的,希望可以帮到你。

问下是怎么指定openmp.so的路径来链接openmp的啊,谢谢

最近在做一个 android 应用,需要提供两套 inference engine(NCNN 和 SNPE [闭源的 没法编译成一个库])。

  • 不加载 SNPE,跑 NCNN 可以
  • 加载了 SNPE, NCNN 会 fail 在 net.load_model() 方法上
    有什么解决方法嘛?谢谢
    @nihui
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Android/sdm845/sdm845:8.1.0/OPM1.171019.026/449:userdebug/test-keys'
Revision: '0'
ABI: 'arm64'
pid: 19518, tid: 19518, name: whim.ai.whimdet  >>> com.whim.ai.whimdet <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
    x0   0000000000000000  x1   0000000000004c3e  x2   0000000000000006  x3   0000000000000008
    x4   0000000004d78450  x5   0000000004d78450  x6   0000000004d78450  x7   00000000001fffff
    x8   0000000000000083  x9   0000000010000000  x10  0000007fdc82bed0  x11  29fa1682f7847293
    x12  29fa1682f7847293  x13  0000000000000001  x14  ffffffffffffffdf  x15  00000077b71778a8
    x16  0000005dc186dfa8  x17  00000077b70fa08c  x18  0000007735a00080  x19  0000000000004c3e
    x20  0000000000004c3e  x21  0000000000000083  x22  0000007717f857f2  x23  000000771c66e9d6
    x24  0000007717f857f6  x25  0000007717ff3000  x26  000000771c66e9d6  x27  00000077baa58a40
    x28  0000007717f7a668  x29  0000007fdc82bf10  x30  00000077b70a08c0
    sp   0000007fdc82bed0  pc   00000077b70a08e8  pstate 0000000060000000
    v0   00000000000000000000000000000200  v1   0000007fdc82bc200000007fdc82bc90
    v2   0000007fdc82bff00000007fdc82c070  v3   00000002000000000000000000000000
    v4   80200000000000000000000000000000  v5   00000000000000000000000000000000
    v6   00000000000000000000040000000000  v7   80200802802008028020080280200802
    v8   00000000000000000000000000000000  v9   00000000000000000000000000000000
    v10  00000000000000000000000000000000  v11  00000000000000000000000000000000
    v12  00000000000000000000000000000000  v13  00000000000000000000000000000000
    v14  00000000000000000000000000000000  v15  00000000000000000000000000000000
    v16  40100401401004014010040140100401  v17  a000000000040000a000040002000000
    v18  80200000000000000000040000000000  v19  0000000008cd4fb00000000000000000
    v20  00000000000000000000000000000000  v21  0000000008cd4fb00000000000000000
    v22  0000000001fe6c4e0000000000000000  v23  0000000008cd4fb00000000000000000
    v24  00000000000000000000000000000000  v25  000000000acbbbfe0000000000000000
    v26  00000000000000000000000000000000  v27  000000000acbbbfe0000000000000000
    v28  00000000000000000000000000000000  v29  000000000acbbbfe0000000000000000
    v30  00000000000000000000000000000000  v31  000000000acbbbfe0000000000000000
    fpsr 08000013  fpcr 00000000

backtrace:
    #00 pc 000000000001e8e8  /system/lib64/libc.so (abort+120)
    #01 pc 000000000039cb24  /data/app/com.whim.ai.whimdet-YJ1HnoMZ0xdGhMzt4DR1fg==/lib/arm64/libwhim-det.so (__kmp_abort_process+44)

stack:
         0000007fdc82be50  0000000000000000
         0000007fdc82be58  206e656562206576
         0000007fdc82be60  0000007fdc82bec0  [stack]
         0000007fdc82be68  0000005dc186b9dc  /system/bin/app_process64 (sigprocmask+288)
         0000007fdc82be70  2e6d6172676f7270
         0000007fdc82be78  7369207461685420
         0000007fdc82be80  ffffffffffffffdf
         0000007fdc82be88  29fa1682f7847293
         0000007fdc82be90  0000007717f857f6  /data/app/com.whim.ai.whimdet-YJ1HnoMZ0xdGhMzt4DR1fg==/lib/arm64/libwhim-det.so
         0000007fdc82be98  000000771c66e9d6  [anon:libc_malloc]
         0000007fdc82bea0  0000007717f857f2  /data/app/com.whim.ai.whimdet-YJ1HnoMZ0xdGhMzt4DR1fg==/lib/arm64/libwhim-det.so
         0000007fdc82bea8  0000000000000000
         0000007fdc82beb0  0000000000004c3e
         0000007fdc82beb8  0000000000004c3e
         0000007fdc82bec0  0000007fdc82bf10  [stack]
         0000007fdc82bec8  00000077b70a08c0  /system/lib64/libc.so (abort+80)
    #00  0000007fdc82bed0  0000007f00000273
         0000007fdc82bed8  7369206f64206f74
         0000007fdc82bee0  0000007717f7a668  /data/app/com.whim.ai.whimdet-YJ1HnoMZ0xdGhMzt4DR1fg==/lib/arm64/libwhim-det.so
         0000007fdc82bee8  2074616874206572
         0000007fdc82bef0  0000000000000000
         0000007fdc82bef8  ffffffffffffffdf
         0000007fdc82bf00  000000771c66e9c0  [anon:libc_malloc]
         0000007fdc82bf08  000000771c736000  [anon:libc_malloc]
         0000007fdc82bf10  0000007fdc82bf20  [stack]
         0000007fdc82bf18  0000007717eb0b28  /data/app/com.whim.ai.whimdet-YJ1HnoMZ0xdGhMzt4DR1fg==/lib/arm64/libwhim-det.so (__kmp_abort_thread)
    #01  0000007fdc82bf20  0000007fdc82c060  [stack]
         0000007fdc82bf28  0000007717eaf564  /data/app/com.whim.ai.whimdet-YJ1HnoMZ0xdGhMzt4DR1fg==/lib/arm64/libwhim-det.so (__kmp_vprintf)
         0000007fdc82bf30  0000000000000000
         0000007fdc82bf38  0000000000000000
         0000007fdc82bf40  0000007fdc82c070  [stack]
         0000007fdc82bf48  0000007fdc82bdf0  [stack]
         0000007fdc82bf50  696c2d6230353265
         0000007fdc82bf58  0000612e706d6f62
         0000007fdc82bf60  0000000000000000
         0000007fdc82bf68  0000000200000000
         0000007fdc82bf70  0000000000000000
         0000007fdc82bf78  8020000000000000
         0000007fdc82bf80  0000000000000000
         0000007fdc82bf88  0000000000000000
         0000007fdc82bf90  0000040000000000
         0000007fdc82bf98  0000000000000000

Maybe I solved the problem.

manually set the allocator with ncnn::PoolAllocator.

eg:
ncnn::PoolAllocator g_blob_pool_allocator;
ncnn::PoolAllocator g_workspace_pool_allocator;

....
//when init model param
this->_opt.workspace_allocator = &(this->g_workspace_pool_allocator);
this->_opt.blob_allocator = &(this->g_blob_pool_allocator);

Maybe your Vulkan Lib version is so lower

@wangyangneu 请教一下,如何在编译.a的时候修改..

如果两个so同时使用一个ncnn.a,需要在编译ncnn.a的时候就加上-Wl,-Bstatic -lomp -Wl,-Bdynamic或者-fstatic-openmp

@wangyangneu 请教一下,如何在编译.a的时候修改..

如果两个so同时使用一个ncnn.a,需要在编译ncnn.a的时候就加上-Wl,-Bstatic -lomp -Wl,-Bdynamic或者-fstatic-openmp

@wangyangneu 您好,我也遇到了同样的问题,我用的是r15c版本的安卓ndk,貌似这个问题是两个动态库依赖同一个静态的libomp.a库导致的。希望指导一下,如何在编译ncnn.a的时候加上-Wl,-Bstatic -lomp -Wl,-Bdynamic, 不知道还有没有其他的解决办法。

@zdx3145 @zhangscth @DolbyYu @glbfor @kimy0909 @onexuan @homwen 上面所讨论的方法我都试过了,还是没有解决,不知道大家有没有其他方法

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jinfagang picture jinfagang  ·  4Comments

lovehuanhuan picture lovehuanhuan  ·  3Comments

nihui picture nihui  ·  5Comments

soham24 picture soham24  ·  3Comments

zsliaoming picture zsliaoming  ·  3Comments