启用 proguard 后的致命信号 11 [英] Fatal signal 11 after enabling proguard
本文介绍了启用 proguard 后的致命信号 11的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！
问题描述
当我创建我的应用程序并从我的 IDE (Eclipse) 启动它时，应用程序运行良好，但是当我构建 APK 时，它崩溃了，但我不知道为什么?它显示致命信号 11 (SIGSEGV) 在 0x0000000c(代码=1).我使用 https://github.com/puelocesar/android-lib-magick 库我的应用.
When I create my app and lauch it from my IDE (Eclipse) app is working great, but when I build APK, it's crashing, but I can't figure out why? It shows Fatal signal 11 (SIGSEGV) at 0x0000000c (code=1). I uses https://github.com/puelocesar/android-lib-magick library in my app.
提前致谢..
06-15 13:39:21.830: I/DEBUG(8010): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
06-15 13:39:21.830: I/DEBUG(8010): Build fingerprint: 'samsung/GT-I9100/GT-I9100:4.0.4/IMM76L/eng.build.20130311.122614:eng/release-keys'
06-15 13:39:21.830: I/DEBUG(8010): pid: 7996, tid: 8064 >>> com.sample.myapp <<<
06-15 13:39:21.830: I/DEBUG(8010): pid: 7996, tid: 8064, pkg name: com.sample.myapp
06-15 13:39:21.830: I/DEBUG(8010): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000000c
06-15 13:39:21.830: I/DEBUG(8010): eax 0b37f318 ebx 0000000c ecx 00000000 edx 08536ce0
06-15 13:39:21.830: I/DEBUG(8010): esi 08536ce0 edi 0b37f318
06-15 13:39:21.830: I/DEBUG(8010): xcs 00000073 xds 0000007b xes 0000007b xfs 00000000 xss 0000007b
06-15 13:39:21.830: I/DEBUG(8010): eip 08536ce6 ebp 0b37f318 esp b4b61a80 flags 00010206
06-15 13:39:22.420: I/DEBUG(8010): #00 eip: 08536ce6
06-15 13:39:22.420: I/DEBUG(8010): #01 eip: 000001d7
06-15 13:39:22.420: I/DEBUG(8010): #02 eip: 00000000
06-15 13:39:22.420: I/DEBUG(8010): stack:
06-15 13:39:22.420: I/DEBUG(8010): #00 b4b61a80 00000002
06-15 13:39:22.420: I/DEBUG(8010): #00 b4b61a84 00000000
06-15 13:39:22.420: I/DEBUG(8010): #00 b4b61a88 00000000
06-15 13:39:22.420: I/DEBUG(8010): #00 b4b61a8c 00000000
06-15 13:39:22.420: I/DEBUG(8010): #00 b4b61a90 00000000
06-15 13:39:22.420: I/DEBUG(8010): #00 b4b61a94 00000000
06-15 13:39:22.420: I/DEBUG(8010): #00 b4b61a98 00000000
06-15 13:39:22.420: I/DEBUG(8010): #00 b4b61a9c 00000000
06-15 13:39:22.420: I/DEBUG(8010): #00 b4b61aa0 00000000
06-15 13:39:22.420: I/DEBUG(8010): #00 b4b61aa4 00000000
06-15 13:39:22.420: I/DEBUG(8010): #00 b4b61aa8 00000000
06-15 13:39:22.420: I/DEBUG(8010): #00 b4b61aac 00000000
06-15 13:39:22.420: I/DEBUG(8010): #00 b4b61ab0 00000000
06-15 13:39:22.420: I/DEBUG(8010): #00 b4b61ab4 00000000
06-15 13:39:22.420: I/DEBUG(8010): #00 b4b61ab8 00000000
06-15 13:39:22.420: I/DEBUG(8010): #00 b4b61abc 00000000
06-15 13:39:22.420: I/DEBUG(8010): ...... ......
06-15 13:39:22.420: I/DEBUG(8010): #01 0b37f31c 000001d7
06-15 13:39:22.420: I/DEBUG(8010): #01 0b37f320 0b37d4a8 [heap]
06-15 13:39:22.420: I/DEBUG(8010): #01 0b37f324 319f96a8 /dev/ashmem/dalvik-heap (deleted)
06-15 13:39:22.420: I/DEBUG(8010): #01 0b37f328 00000000
06-15 13:39:22.420: I/DEBUG(8010): #01 0b37f32c 1d700001
06-15 13:39:22.420: I/DEBUG(8010): #01 0b37f330 00000000
06-15 13:39:22.420: I/DEBUG(8010): #01 0b37f334 3ba1fe84
06-15 13:39:22.420: I/DEBUG(8010): #01 0b37f338 109ffc40
06-15 13:39:22.420: I/DEBUG(8010): #01 0b37f33c 3ba1fe7c
06-15 13:39:22.420: I/DEBUG(8010): #01 0b37f340 31a165e8 /dev/ashmem/dalvik-heap (deleted)
06-15 13:39:22.420: I/DEBUG(8010): #01 0b37f344 109ffc54
06-15 13:39:22.420: I/DEBUG(8010): #01 0b37f348 3120282c /system/lib/libdvm.so-arm
06-15 13:39:22.420: I/DEBUG(8010): #01 0b37f34c 109ffbe8
06-15 13:39:22.420: I/DEBUG(8010): #01 0b37f350 311a4438 /system/lib/libdvm.so-arm (_Z20dvmDecodeIndirectRefP6ThreadP8_jobject)
06-15 13:39:22.420: I/DEBUG(8010): #01 0b37f354 311a68ec /system/lib/libdvm.so-arm
06-15 13:39:22.420: I/DEBUG(8010): #01 0b37f358 00000010
06-15 13:39:22.420: I/DEBUG(8010): ...... ......
06-15 13:39:22.420: I/DEBUG(8010): #02 319f96ac 00000000
06-15 13:39:22.420: I/DEBUG(8010): #02 319f96b0 00000000
06-15 13:39:22.420: I/DEBUG(8010): #02 319f96b4 00000000
06-15 13:39:22.420: I/DEBUG(8010): #02 319f96b8 00000018
06-15 13:39:22.420: I/DEBUG(8010): #02 319f96bc 00000023
06-15 13:39:22.420: I/DEBUG(8010): #02 319f96c0 313b90b8 /dev/ashmem/dalvik-heap (deleted)
06-15 13:39:22.420: I/DEBUG(8010): #02 319f96c4 00000000
06-15 13:39:22.420: I/DEBUG(8010): #02 319f96c8 319f96e0 /dev/ashmem/dalvik-heap (deleted)
06-15 13:39:22.420: I/DEBUG(8010): #02 319f96cc 0e3baed4
06-15 13:39:22.420: I/DEBUG(8010): #02 319f96d0 00000000
06-15 13:39:22.420: I/DEBUG(8010): #02 319f96d4 00000029
06-15 13:39:22.420: I/DEBUG(8010): #02 319f96d8 00000000
06-15 13:39:22.420: I/DEBUG(8010): #02 319f96dc 0000006b
06-15 13:39:22.420: I/DEBUG(8010): #02 319f96e0 313b9928 /dev/ashmem/dalvik-heap (deleted)
06-15 13:39:22.420: I/DEBUG(8010): #02 319f96e4 00000000
06-15 13:39:22.420: I/DEBUG(8010): #02 319f96e8 00000029
06-15 13:39:22.420: I/DEBUG(8010): ...... ......
这是我的代码
protected Void doInBackground(Void... params) {
try{
ImageInfo info=new ImageInfo(selectedImagePath);
MagickImage imageCMYK = new MagickImage(info);
if(imageCMYK.getColorspace()==12){
bitmap=getCMYKImageFromPath(selectedImagePath);
}
else {
//do something
}
}
}catch (Exception e) {
e.printStackTrace();
}
return null;
}
这是检索图像的代码
public Bitmap getCMYKImageFromPath(String path) {
try {
ImageInfo info = new ImageInfo(path); // where the CMYK image is
MagickImage imageCMYK = new MagickImage(info);
Log.d("DEBUG", "ColorSpace BEFORE => " + imageCMYK.getColorspace());
boolean status = imageCMYK.transformRgbImage(ColorspaceType.CMYKColorspace);
Log.d("DEBUG", "ColorSpace AFTER => " + imageCMYK.getColorspace() + ", success = " + status);
bitmap = MagickBitmap.ToBitmap(imageCMYK);
} catch (Exception e) {
e.printStackTrace();
}
return bitmap;
}
推荐答案
如果本机库使用反射回调到 Java 代码中，则需要保留被调用的类、字段和方法.否则，ProGuard 可能会重命名甚至删除它们，从而导致本机代码出现混乱的崩溃.在不了解库的内部结构的情况下，您可以保留其所有类、字段和方法:
If the native library is using reflection to call back into the Java code, you need to preserve the called classes, fields, and methods. Otherwise, ProGuard may rename or even remove them, leading to a confusing crash in the native code. Without knowing the internals of the library, you could preserve all of its classes, fields, and methods:
-keep class magick.** { *; }
-keep class fakeawt.** { *; }
如果这有帮助，您可以尝试缩小这些选项的范围，以保持最少的类、字段和方法.
If this helps, you could try narrowing these options down to keep the minimal number of classes, fields, and methods.
这篇关于启用 proguard 后的致命信号 11的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
查看全文
