尝试loadLibrary（）时应用程序崩溃，4.1.1上的pthread_create问题？

时间：2012-10-02 18:47:48

标签： multithreading android-ndk java-native-interface cross-compiling libc

我试图通过尝试加载我使用System.loadLibrary（）交叉编译的库来调试崩溃。我已经能够在运行4.0.4（ICS）的任何设备上成功加载此库，但它在我运行4.1.1（JB）的所有设备上崩溃。在libc中运行到pthread_create（）时似乎崩溃了：

10-01 14:25:34.173: D/dalvikvm(8215): Trying to load lib /data/data/com.gnychis.awmon/lib/libtshark.so 0x410fb430
10-01 14:25:34.181: A/libc(8215): Fatal signal 11 (SIGSEGV) at 0x5dfaa01c (code=2), thread 8232 (AsyncTask #1)
// And here is the end of the stack....
I/DEBUG   (  246):     #10  pc 0001263c  /system/lib/libc.so (pthread_create+180)

这是一个更长的崩溃日志，它涉及显示整个堆栈跟踪，您将看到它以libc和pthread_create结束：

D/dalvikvm(26364): Trying to load lib /data/data/com.gnychis.awmon/lib/libtshark.so 0x410a5ee0
F/libc    (26364): Fatal signal 11 (SIGSEGV) at 0x5dff301c (code=2), thread 27345 (AsyncTask #1)
D/AndroidRuntime(27404): Calling main entry com.android.commands.am.Am
I/DEBUG   (  246): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   (  246): Build fingerprint: 'd2uc-user 4.0.4 IMM76D I747UCALEM release-keys'
I/DEBUG   (  246): pid: 26364, tid: 27345, name: AsyncTask #1  >>> com.gnychis.awmon <<<
I/DEBUG   (  246): signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 5dff301c
D/AndroidRuntime(27404): Shutting down VM
D/dalvikvm(27404): GC_CONCURRENT freed 99K, 88% free 498K/4096K, paused 1ms+1ms, total 7ms
I/AndroidRuntime(27404): NOTE: attach of thread 'Binder_3' failed
I/DEBUG   (  246):     r0 80000000  r1 02b1a000  r2 00000005  r3 5dff3000
I/DEBUG   (  246):     r4 40102894  r5 4010aaec  r6 00000000  r7 00000029
I/DEBUG   (  246):     r8 00000029  r9 5dff3000  sl 60871000  fp 02b1a000
I/DEBUG   (  246):     ip 00000005  sp 5d95ace0  lr 6004d1bb  pc 400ec6e0  cpsr 600d0030
I/DEBUG   (  246):     d0  61642f617461642f  d1  672e6d6f632f6174
I/DEBUG   (  246):     d2  612e73696863796e  d3  62696c2f6e6f6d77
I/DEBUG   (  246):     d4  00000000000e16f0  d5  000000000000695f
I/DEBUG   (  246):     d6  000000000002a715  d7  0000012f00000000
I/DEBUG   (  246):     d8  0000000000000000  d9  0000000000000000
I/DEBUG   (  246):     d10 0000000000000000  d11 0000000000000000
I/DEBUG   (  246):     d12 0000000000000000  d13 0000000000000000
I/DEBUG   (  246):     d14 0000000000000000  d15 0000000000000000
I/DEBUG   (  246):     d16 7420676e69797254  d17 6c2064616f6c206f
I/DEBUG   (  246):     d18 0063002f00610074  d19 0067002e006d006f
I/DEBUG   (  246):     d20 006800630079006e  d21 0061002e00730069
I/DEBUG   (  246):     d22 006e006f006d0077  d23 00620069006c002f
I/DEBUG   (  246):     d24 000000000000e16f  d25 0000000000000000
I/DEBUG   (  246):     d26 000000000000695f  d27 0000000000000000
I/DEBUG   (  246):     d28 000000000000695f  d29 0000000000000000
I/DEBUG   (  246):     d30 0000000500000005  d31 0000000500000005
I/DEBUG   (  246):     scr 60000012
I/DEBUG   (  246): 
I/DEBUG   (  246): backtrace:
I/DEBUG   (  246):     #00  pc 000046e0  /system/bin/linker
I/DEBUG   (  246):     #01  pc 00005b6f  /system/bin/linker
I/DEBUG   (  246):     #02  pc 0004f73b  /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+186)
I/DEBUG   (  246):     #03  pc 000662bd  /system/lib/libdvm.so
I/DEBUG   (  246):     #04  pc 000274e0  /system/lib/libdvm.so
I/DEBUG   (  246):     #05  pc 0002be08  /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+180)
I/DEBUG   (  246):     #06  pc 0005f9f5  /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+272)
I/DEBUG   (  246):     #07  pc 0005fa1f  /system/lib/libdvm.so (dvmCallMethod(Thread*, Method const*, Object*, JValue*, ...)+20)
I/DEBUG   (  246):     #08  pc 000545ab  /system/lib/libdvm.so
I/DEBUG   (  246):     #09  pc 00012ee4  /system/lib/libc.so (__thread_entry+48)
I/DEBUG   (  246):     #10  pc 0001263c  /system/lib/libc.so (pthread_create+180)

有趣的是，如果我在库上使用arm-eabi-objdump，地址1263c似乎是在尝试执行pthread_clone的时候：

$ arm-eabi-objdump -S /tmp/libc.so | grep 1263c
1263c:       ebffed71        bl      dc08 <__pthread_clone>

有没有人知道为什么这不适用于4.1.1？另外，为什么我的崩溃日志顶部的“构建指纹”显示：

Build fingerprint: 'd2uc-user 4.0.4'

这可能是它为什么没有在4.1.1上运行的根本问题吗？我正在使用最新的NDK（r8b），其中android-14作为arm-eabi-4.4.3工具链的平台。

非常感谢任何帮助/指导。

编辑：我的大多数崩溃现在似乎都发生在......我在这里丢了一个符号吗？

D/dalvikvm(11194): Trying to load lib /data/data/com.gnychis.awmon/lib/libtshark.so 0x4130fac8
F/libc    (11194): Fatal signal 11 (SIGSEGV) at 0x5df6b01c (code=2), thread 11230 (AsyncTask #1)
I/DEBUG   ( 7539): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   ( 7539): Build fingerprint: 'd2uc-user 4.0.4 IMM76D I747UCALEM release-keys'
I/DEBUG   ( 7539): pid: 11194, tid: 11230, name: AsyncTask #1  >>> com.gnychis.awmon <<<
I/DEBUG   ( 7539): signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 5df6b01c
I/DEBUG   ( 7539):     r0 80000000  r1 02b1b000  r2 00000005  r3 5df6b000
I/DEBUG   ( 7539):     r4 400e8894  r5 400f0aec  r6 00000000  r7 0000002a
I/DEBUG   ( 7539):     r8 0000002a  r9 5df6b000  sl 607ea000  fp 02b1b000
I/DEBUG   ( 7539):     ip 00000005  sp 5d8d2cd0  lr 5ffc5fff  pc 400d26e0  cpsr 600d0030
I/DEBUG   ( 7539):     d0  61642f617461642f  d1  672e6d6f632f6174
I/DEBUG   ( 7539):     d2  612e73696863796e  d3  62696c2f6e6f6d77
I/DEBUG   ( 7539):     d4  00000000000e16f0  d5  000000000000695f
I/DEBUG   ( 7539):     d6  000000000005a6e8  d7  0000012f00000000
I/DEBUG   ( 7539):     d8  0000000000000000  d9  0000000000000000
I/DEBUG   ( 7539):     d10 0000000000000000  d11 0000000000000000
I/DEBUG   ( 7539):     d12 0000000000000000  d13 0000000000000000
I/DEBUG   ( 7539):     d14 0000000000000000  d15 0000000000000000
I/DEBUG   ( 7539):     d16 7420676e69797254  d17 6c2064616f6c206f
I/DEBUG   ( 7539):     d18 00000000006f7478  d19 0067002e006d006f
I/DEBUG   ( 7539):     d20 006800630079006e  d21 0061002e00730069
I/DEBUG   ( 7539):     d22 006e006f006d0077  d23 00620069006c002f
I/DEBUG   ( 7539):     d24 000000000000e16f  d25 0000000000000000
I/DEBUG   ( 7539):     d26 000000000000695f  d27 0000000000000000
I/DEBUG   ( 7539):     d28 000000000000695f  d29 0000000000000000
I/DEBUG   ( 7539):     d30 0000000d0000000d  d31 0000000d0000000d
I/DEBUG   ( 7539):     scr 60000012
I/DEBUG   ( 7539): 
I/DEBUG   ( 7539): backtrace:
I/DEBUG   ( 7539):     #00  pc 000046e0  /system/bin/linker
I/DEBUG   ( 7539):     #01  pc 00005b6f  /system/bin/linker
I/DEBUG   ( 7539):     #02  pc 0004f73b  /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+186)
I/DEBUG   ( 7539):     #03  pc 000662bd  /system/lib/libdvm.so
I/DEBUG   ( 7539):     #04  pc 00027524  /system/lib/libdvm.so
I/DEBUG   ( 7539):     #05  pc 000fedd8  <unknown>

2 个答案:

答案 0 :(得分：0)

见Android JNI: Calling System.loadLibrary() causes SEGV。您的本地库是否有JNI_OnLoad（）？如果此函数调用JNI函数，请尝试从主（UI）线程调用它。

答案 1 :(得分：0)

事实证明我的工具链太旧了。我在AOSP项目中升级到了更新的arm-eabi工具链，现在库链接得很好！

相关问题
最新问题