私は他の記事を読んで、AndroidアプリでSIGSEGV
を取得した理由を追跡しています。 Canvasの使用に関連したNullPointersの可能性について私のアプリを洗練することを計画していますが、私のSIGSEGV
は毎回異なるメモリアドレスを使用しています。それに私はcode=1
とcode=2
を見ました。メモリアドレスが0x00000000
であるならば、私はそれがNullPointerであるという手がかりを持っているでしょう。
私が最後に手に入れたのはcode=2
です。
A/libc(4969): Fatal signal 11 (SIGSEGV) at 0x42a637d9 (code=2)
これを追跡する方法について何か提案はありますか?
私は疑いを持っていますが、私はまだそれを試すことに熱心ではありません。私のアプリはオフラインマッピングにOSMDroid APIを使用しています。 OverlayItemクラスは、地図上のマーカー/ノードを表します。地図上に表示されるOverlayItemを作成するためにネットワーク経由でデータを収集するサービスがあります。設計を単純化するために、OverlayItemを自分のNodeOverlayItemクラスに拡張しました。このクラスには、UIアクティビティとサービスで使用する追加の属性がいくつか含まれています。これにより、UIとサービスに関する単一の項目情報が得られました。何かが変わったときにUIマップを更新するために、Intentsを使ってActivityにブロードキャストしました。 ActivityがServiceにバインドし、NodeOverlayItemのリストを取得するServiceメソッドがあります。私はそれがOSMDroid APIのOverlayItemの使用と、同時に私のサービスがノード情報を更新しているのかもしれないと思います。 (並行性の問題)
これを書いているとき、私はそれが本当に問題だと思います。頭痛の種はNodeOverlayItemからNodeとOverlayItemを分離していません、それはActivityがNodeからいくつかのデータを必要とするということです、それはサービスが保持するということです。さらに、アクティビティが作成されたとき(onResumeなど)、サービスがアクティビティの停止中に維持していたNodeデータからOverlayItemオブジェクトを再作成する必要があります。例えばアプリを起動すると、Serviceがデータを収集し、UIがそれを表示し、Homeに移動してからアプリに戻ると、Activityは最新のServiceノードデータからOverlayItemを取得して再作成する必要があります。
これは素晴らしい質問でも明確な質問でもないことを私は知っています。私のSOすべての質問がニッチかあいまいなものであるようなものです。もし誰かがそれらのSIGSEGV
エラーをどう解釈するかについての提案があれば、それは大いに感謝されるでしょう!
UPDATEこれがデバッグセッション中にキャプチャされた最新のクラッシュです。私はこれらのデバイスのうち3つをテストに使用していますが、開発中やテスト中にこれらすべてが確実にクラッシュするわけではありません。 GCのログ記録を記録できるように、もう少し追加しました。あなたは問題がおそらくメモリ枯渇に関連していないのを見ることができます。
03-03 02:02:38.328: I/CommService(7477): Received packet from: 192.168.1.102
03-03 02:02:38.328: I/CommService(7477): Already processed this packet. It's a re-broadcast from another node, or from myself. It's not a repeat broadcast though.
03-03 02:02:38.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:38.460: D/CommService(7477): Monitoring nodes...
03-03 02:02:38.515: D/dalvikvm(7477): GC_CONCURRENT freed 2050K, 16% free 17151K/20359K, paused 3ms+6ms
03-03 02:02:38.515: I/CommService(7477): Received packet from: 192.168.1.102
03-03 02:02:38.515: D/CommService(7477): Forwarding packet (4f68802cf10684a83ac4936ebb3c934d) along to other nodes.
03-03 02:02:38.609: I/CommService(7477): Received packet from: 192.168.1.100
03-03 02:02:38.609: D/CommService(7477): Forwarding packet (e4bc81e91ec92d06f83e03068f52ab4) along to other nodes.
03-03 02:02:38.609: D/CommService(7477): Already processed this packet: 4204a5b27745ffe5e4f8458e227044bf
03-03 02:02:38.609: A/libc(7477): Fatal signal 11 (SIGSEGV) at 0x68f52abc (code=1)
03-03 02:02:38.914: I/DEBUG(4008): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-03 02:02:38.914: I/DEBUG(4008): Build fingerprint: 'Lenovo/IdeaTab_A1107/A1107:4.0.4/MR1/eng.user.20120719.150703:user/release-keys'
03-03 02:02:38.914: I/DEBUG(4008): pid: 7477, tid: 7712 >>> com.test.testm <<<
03-03 02:02:38.914: I/DEBUG(4008): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 68f52abc
03-03 02:02:38.914: I/DEBUG(4008): r0 68f52ab4 r1 412ef268 r2 4d9c3bf4 r3 412ef268
03-03 02:02:38.914: I/DEBUG(4008): r4 001ad8f8 r5 4d9c3bf4 r6 412ef268 r7 4c479df8
03-03 02:02:38.914: I/DEBUG(4008): r8 4d9c3c0c r9 4c479dec 10 46cf260a fp 4d9c3c24
03-03 02:02:38.914: I/DEBUG(4008): ip 40262a04 sp 4d9c3bc8 lr 402d01dd pc 402d0182 cpsr 00000030
03-03 02:02:38.914: I/DEBUG(4008): d0 00000001000c0102 d1 3a22364574614c7d
03-03 02:02:38.914: I/DEBUG(4008): d2 403fc0000000007d d3 363737343433350a
03-03 02:02:38.914: I/DEBUG(4008): d4 49544341223a2273 d5 6f6567222c224556
03-03 02:02:38.914: I/DEBUG(4008): d6 3a223645676e6f4c d7 000000013835372d
03-03 02:02:38.914: I/DEBUG(4008): d8 0000000000000000 d9 4040000000000000
03-03 02:02:38.914: I/DEBUG(4008): d10 0000000000000000 d11 4040000000000000
03-03 02:02:38.914: I/DEBUG(4008): d12 4040000000000000 d13 0000000000000021
03-03 02:02:38.914: I/DEBUG(4008): d14 0000000000000000 d15 0000000000000000
03-03 02:02:38.914: I/DEBUG(4008): d16 3fe62e42fefa39ef d17 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d18 3fe62e42fee00000 d19 0000000000000000
03-03 02:02:38.914: I/DEBUG(4008): d20 0000000000000000 d21 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d22 4028000000000000 d23 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d24 0000000000000000 d25 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d26 0000000000000000 d27 c028000000000000
03-03 02:02:38.914: I/DEBUG(4008): d28 0000000000000000 d29 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d30 3ff0000000000000 d31 3fecccccb5c28f6e
03-03 02:02:38.914: I/DEBUG(4008): scr 60000013
03-03 02:02:39.046: I/DEBUG(4008): #00 pc 0006b182 /system/lib/libcrypto.so (EVP_DigestFinal_ex)
03-03 02:02:39.046: I/DEBUG(4008): #01 pc 0006b1d8 /system/lib/libcrypto.so (EVP_DigestFinal)
03-03 02:02:39.054: I/DEBUG(4008): #02 pc 0001f814 /system/lib/libnativehelper.so
03-03 02:02:39.054: I/DEBUG(4008): #03 pc 0001ec30 /system/lib/libdvm.so (dvmPlatformInvoke)
03-03 02:02:39.054: I/DEBUG(4008): #04 pc 00058c70 /system/lib/libdvm.so (_Z16dvmCallJNIMethodPKjP6JValuePK6MethodP6Thread)
03-03 02:02:39.054: I/DEBUG(4008): code around pc:
03-03 02:02:39.054: I/DEBUG(4008): 402d0160 0003151e 4604b570 f7ff460d 4620ff81 ....p..F.F.... F
03-03 02:02:39.054: I/DEBUG(4008): 402d0170 f7ff4629 bd70ff93 4604b570 460e6800 )F....p.p..F.h.F
03-03 02:02:39.054: I/DEBUG(4008): 402d0180 68834615 dd062b40 21fa4810 44784a10 .F.h@+...H.!.JxD
03-03 02:02:39.054: I/DEBUG(4008): 402d0190 f7c8447a 6821f80f 698a4620 47904631 zD....!h F.i1F.G
03-03 02:02:39.054: I/DEBUG(4008): 402d01a0 b1154606 68836820 6822602b b12b6a13 .F.. h.h+`"h.j+.
03-03 02:02:39.054: I/DEBUG(4008): code around lr:
03-03 02:02:39.054: I/DEBUG(4008): 402d01bc 68e06821 21006c4a ea0af7c4 bd704630 !h.hJl.!....0Fp.
03-03 02:02:39.054: I/DEBUG(4008): 402d01cc 00031492 000314b5 4604b570 ffcef7ff ........p..F....
03-03 02:02:39.054: I/DEBUG(4008): 402d01dc 46204605 ff12f7ff bd704628 4604b573 .F F....(Fp.s..F
03-03 02:02:39.054: I/DEBUG(4008): 402d01ec 2102460d fb36f002 42ab6823 b123d020 .F.!..6.#h.B .#.
03-03 02:02:39.054: I/DEBUG(4008): 402d01fc b1136c5b f7c868e0 68a0fccf 05c26025 [l...h.....h%`..
03-03 02:02:39.054: I/DEBUG(4008): memory map around addr 68f52abc:
03-03 02:02:39.054: I/DEBUG(4008): 4d8c5000-4d9c4000
03-03 02:02:39.054: I/DEBUG(4008): (no map for address)
03-03 02:02:39.054: I/DEBUG(4008): b0001000-b0009000 /system/bin/linker
03-03 02:02:39.054: I/DEBUG(4008): stack:
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b88 408d1f90 /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b8c 412ef258 /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b90 00000001
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b94 408d6c58 /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b98 408d6fa8 /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b9c 4c479dec
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3ba0 46cf260a /system/framework/core.odex
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3ba4 408735e7 /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3ba8 412ef258 /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bac 002bf070 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bb0 412ef258 /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bb4 00000000
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bb8 412ef268 /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bbc 00000000
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bc0 df0027ad
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bc4 00000000
03-03 02:02:39.054: I/DEBUG(4008): #00 4d9c3bc8 001ad8f8 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bcc 002ae0b8 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bd0 00000004
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bd4 402d01dd /system/lib/libcrypto.so
03-03 02:02:39.054: I/DEBUG(4008): #01 4d9c3bd8 001ad8f8 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bdc 002ae0b8 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3be0 00000004
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3be4 4024e817 /system/lib/libnativehelper.so
03-03 02:02:39.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:39.500: D/CommService(7477): Monitoring nodes...
03-03 02:02:39.500: D/dalvikvm(7477): GC_FOR_ALLOC freed 2073K, 16% free 17118K/20359K, paused 51ms
03-03 02:02:39.632: D/dalvikvm(7477): GC_CONCURRENT freed 1998K, 16% free 17162K/20359K, paused 2ms+4ms
03-03 02:02:40.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:40.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:40.562: D/dalvikvm(7477): GC_CONCURRENT freed 2045K, 16% free 17158K/20359K, paused 3ms+4ms
03-03 02:02:41.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:41.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:41.531: D/dalvikvm(7477): GC_CONCURRENT freed 2045K, 16% free 17154K/20359K, paused 3ms+12ms
03-03 02:02:42.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:42.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:42.507: D/dalvikvm(7477): GC_CONCURRENT freed 2068K, 16% free 17128K/20359K, paused 3ms+4ms
03-03 02:02:42.679: D/dalvikvm(7477): GC_CONCURRENT freed 2006K, 16% free 17161K/20359K, paused 2ms+12ms
03-03 02:02:43.140: I/BootReceiver(1236): Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)
03-03 02:02:43.210: D/dalvikvm(1236): GC_FOR_ALLOC freed 912K, 17% free 10207K/12295K, paused 62ms
03-03 02:02:43.265: D/dalvikvm(1236): GC_FOR_ALLOC freed 243K, 16% free 10374K/12295K, paused 49ms
03-03 02:02:43.265: I/dalvikvm-heap(1236): Grow heap (frag case) to 10.507MB for 196628-byte allocation
OK!実際にコメントと回答を提出してくれた人たちには本当に申し訳ありませんが、私は問題を発見しました。これが自分の個人的なSIGSEGVを突き止めようとしている多くの人を助けることになるとは思わないが、私の(そしてそれは非常に困難だった)完全にこれに関連していた:
https://code.google.com/p/Android/issues/detail?id=8709
私のダンプに入っているlibcrypto.soは私を閉じ込めるようにしました。パケットをすでに見たかどうかを判断しようとしたときにパケットデータのMD5ハッシュを作成し、持っていた場合はスキップします。ある時点で、これはハッシュの追跡に関連する醜いスレッドの問題だと思いましたが、それはJava.security.MessageDigestクラスであることがわかりました!スレッドセーフではありません。
デバイスのUUIDとタイムスタンプに基づいて、すべてのパケットに詰め込んでいたUIDと交換しました。それ以来問題ありません。
私が私の状況にあったものに与えることができるレッスンは、あなたが100%Javaアプリケーションであっても、手がかりのためにクラッシュダンプに記されているネイティブライブラリとシンボルに注意を払うことであると思います。 SIGSEGV +のgoogling + lib .soという名前は、無駄なcode = 1などよりはるかに長くなります。次に、Javaアプリケーションがネイティブコードに触れる可能性がある場所について考えてみましょう。私はそれがCanvasがnullである何かを描いていた(SIGSEGVでグーグルした最も一般的なケースである)Service + UIスレッドの問題であると誤解し、それが私が書いたコードに完全に関連した可能性を無視しましたクラッシュダンプ内のlib .soに関連しています。当然のことながら、Java.securityはlibcrypto.soのネイティブコンポーネントを使用して高速化しています。そのため、一度調べてみると、Android + SIGSEGV + libcrypto.soを検索し、文書化されている問題を見つけました。がんばろう!
まず、墓石スタックトレースを取得します。アプリがクラッシュするたびに印刷されます。このようなもの:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'XXXXXXXXX'
pid: 1658, tid: 13086 >>> system_server <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 64696f7e
r0 00000000 r1 00000001 r2 ad12d1e8 r3 7373654d
r4 64696f72 r5 00000406 r6 00974130 r7 40d14008
r8 4b857b88 r9 4685adb4 10 00974130 fp 4b857ed8
ip 00000000 sp 4b857b50 lr afd11108 pc ad115ebc cpsr 20000030
d0 4040000040000000 d1 0000004200000003
d2 4e72cd924285e370 d3 00e81fe04b1b64d8
d4 3fbc71c7009b64d8 d5 3fe999999999999a
d6 4010000000000000 d7 4000000000000000
d8 4000000000000000 d9 0000000000000000
d10 0000000000000000 d11 0000000000000000
d12 0000000000000000 d13 0000000000000000
d14 0000000000000000 d15 0000000000000000
scr 80000012
#00 pc 000108d8 /system/lib/libc.so
#01 pc 0003724c /system/lib/libxvi020.so
#02 pc 0000ce02 /system/lib/libxvi020.so
#03 pc 0000d672 /system/lib/libxvi020.so
#04 pc 00010cce /system/lib/libxvi020.so
#05 pc 00004432 /system/lib/libwimax_jni.so
#06 pc 00011e74 /system/lib/libdvm.so
#07 pc 0004354a /system/lib/libdvm.so
#08 pc 00017088 /system/lib/libdvm.so
#09 pc 0001c210 /system/lib/libdvm.so
#10 pc 0001b0f8 /system/lib/libdvm.so
#11 pc 00059c24 /system/lib/libdvm.so
#12 pc 00059e3c /system/lib/libdvm.so
#13 pc 0004e19e /system/lib/libdvm.so
#14 pc 00011b94 /system/lib/libc.so
#15 pc 0001173c /system/lib/libc.so
code around pc:
ad115e9c 4620eddc bf00bd70 0001736e 0001734e
ad115eac 4605b570 447c4c0a f7f44620 e006edc8
ad115ebc 42ab68e3 68a0d103 f7f42122 6864edd2
ad115ecc d1f52c00 44784803 edbef7f4 bf00bd70
ad115edc 00017332 00017312 2100b51f 46682210
code around lr:
afd110e8 e2166903 1a000018 e5945000 e1a02004
afd110f8 e2055a02 e1a00005 e3851001 ebffed92
afd11108 e3500000 13856002 1a000001 ea000009
afd11118 ebfffe50 e1a01004 e1a00006 ebffed92
afd11128 e1a01005 e1550000 e1a02006 e3a03000
stack:
4b857b10 40e43be8
4b857b14 00857280
4b857b18 00000000
4b857b1c 034e8968
4b857b20 ad118ce9 /system/lib/libnativehelper.so
4b857b24 00000002
4b857b28 00000406
次に、addr2line
ユーティリティ(NDKツールチェーンで見つけます)を使用して、クラッシュした関数を見つけます。このサンプルでは、
addr2line -e -f libc.so 0001173c
そして、あなたはあなたが問題を起こした場所を見るでしょう。 libcに入っているので、もちろんこれは役に立ちません。
そのため、arm-eabi-objdump
のユーティリティを組み合わせて最終的なターゲットを見つけることができます。
私を信じて、それは大変な作業です。
更新のためだけに。私は私がNDK文書を注意深く読んでもらうために今日までずっとソースツリー全体からAndroidネイティブビルドをしていたと思います。 NDK-r6のリリース以来、ndk-stack
と呼ばれるユーティリティを提供してきました。
以下はNDK-r9タールボールを使った公式NDK文書の内容です。
概要:
ndk-stack
は、 'adb logcat'の出力に表示されるスタックトレースをフィルタリングし、共有ライブラリ内の任意のアドレスを対応する:値に置き換えることができるシンプルなツールです。
一言で言えば、それは何かのように翻訳されます:
I/DEBUG ( 31): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 31): Build fingerprint: 'generic/google_sdk/generic/:2.2/FRF91/43546:eng/test-keys'
I/DEBUG ( 31): pid: 351, tid: 351 %gt;%gt;%gt; /data/local/ndk-tests/crasher <<<
I/DEBUG ( 31): signal 11 (SIGSEGV), fault addr 0d9f00d8
I/DEBUG ( 31): r0 0000af88 r1 0000a008 r2 baadf00d r3 0d9f00d8
I/DEBUG ( 31): r4 00000004 r5 0000a008 r6 0000af88 r7 00013c44
I/DEBUG ( 31): r8 00000000 r9 00000000 10 00000000 fp 00000000
I/DEBUG ( 31): ip 0000959c sp be956cc8 lr 00008403 pc 0000841e cpsr 60000030
I/DEBUG ( 31): #00 pc 0000841e /data/local/ndk-tests/crasher
I/DEBUG ( 31): #01 pc 000083fe /data/local/ndk-tests/crasher
I/DEBUG ( 31): #02 pc 000083f6 /data/local/ndk-tests/crasher
I/DEBUG ( 31): #03 pc 000191ac /system/lib/libc.so
I/DEBUG ( 31): #04 pc 000083ea /data/local/ndk-tests/crasher
I/DEBUG ( 31): #05 pc 00008458 /data/local/ndk-tests/crasher
I/DEBUG ( 31): #06 pc 0000d362 /system/lib/libc.so
I/DEBUG ( 31):
より読みやすい出力に:
********** Crash dump: **********
Build fingerprint: 'generic/google_sdk/generic/:2.2/FRF91/43546:eng/test-keys'
pid: 351, tid: 351 >>> /data/local/ndk-tests/crasher <<<
signal 11 (SIGSEGV), fault addr 0d9f00d8
Stack frame #00 pc 0000841e /data/local/ndk-tests/crasher : Routine Zoo in /tmp/foo/crasher/jni/Zoo.c:13
Stack frame #01 pc 000083fe /data/local/ndk-tests/crasher : Routine bar in /tmp/foo/crasher/jni/bar.c:5
Stack frame #02 pc 000083f6 /data/local/ndk-tests/crasher : Routine my_comparison in /tmp/foo/crasher/jni/foo.c:9
Stack frame #03 pc 000191ac /system/lib/libc.so
Stack frame #04 pc 000083ea /data/local/ndk-tests/crasher : Routine foo in /tmp/foo/crasher/jni/foo.c:14
Stack frame #05 pc 00008458 /data/local/ndk-tests/crasher : Routine main in /tmp/foo/crasher/jni/main.c:19
Stack frame #06 pc 0000d362 /system/lib/libc.so
使用法:
これを行うには、まずアプリケーションの共有ライブラリのシンボリックバージョンを含むディレクトリが必要になります。 NDKビルドシステム(ndk-build
)を使用する場合、これらは常に$ PROJECT_PATH/obj/local /の下にあります。ここで、デバイスのABIを表します(つまり、デフォルトでarmeabi
)。
あなたはlogcat
というテキストをプログラムへの直接の入力として送ることができます。例えば:
adb logcat | $NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi
あるいは、-dumpオプションを使ってlogcatを入力ファイルとして指定することもできます。
adb logcat > /tmp/foo.txt
$NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi -dump foo.txt
重要:
ツールはlogcat
の出力の中で開始を含む最初の行を探します。
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
トレースをコピー/ペーストするときは、トレースからこの行を忘れないでください。そうしないと、ndk-stack
が正しく機能しません。
TODO:
将来のバージョンのndk-stack
は、adb logcat
を起動してライブラリパスを自動的に選択しようとします。今のところ、あなたは手動でこれらのステップをしなければならないでしょう。
現時点では、ndk-stack
はデバッグ情報を持たないライブラリを扱いません。 (例えば上記のlibc.soの例のように)与えられたPCアドレスに最も近い関数エントリポイントを検出しようと試みることは有用かもしれません。
オブジェクトをgson変換文字列として共有設定に保存することで、このエラーが発生しました。 gson文字列は良くありませんでしたので、オブジェクトの取得と逆シリアル化は実際には正しく機能しませんでした。これは、その後のオブジェクトへのアクセスによってこのエラーが発生したことを意味します。怖い:)
私はまたこのエラーを何度も受けました、そしてそれを解決しました。このエラーはネイティブ側のメモリ管理の場合に直面するでしょう。
あなたのアプリケーションは、そのアドレス空間の外側のメモリにアクセスしています。これはおそらく無効なポインタアクセスです。 SIGSEGV =ネイティブコード内のセグメンテーション違反。 Javaコードでは発生していないので、詳細なスタックトレースは表示されません。ただし、アプリケーションプロセスがクラッシュした後に少し目を向けると、logcatにスタックトレース情報が表示されることがあります。ファイル内の行番号はわかりませんが、コールチェーンで使用されているオブジェクトファイルとアドレスはわかります。そこから、コードのどの部分に問題があるのかがわかります。ターゲットプロセスへのgdbネイティブ接続を設定し、それをデバッガで捕捉することもできます。
今日私はFatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 18161
問題に直面し、私はこれを解決するために半日奮闘しました。
私はキャッシュをクリアし、.gradleファイルを削除するなど、さまざまなことを試みました。
ようやく私はdisable Instant Run
になり、そして今私は二度とこの問題を得ていません。今すぐ私のアプリケーションもインスタントランを有効にした後に働いています。それはインスタントランの問題かもしれません、インスタントランを無効にして有効にしてみてください
から この 答え:
Android Studioの[設定]または[設定](MAC用) - > [ビルド]、[実行]、[デプロイメント] - > [インスタントラン]に移動します。
次に、上部にある[インスタントランを有効にする]チェックボックスをオフにします。
onDraw()
の外で「キャンバス」にアクセスしようとしたときにこのエラーが発生しました
private Canvas canvas;
@Override
protected void onDraw(Canvas canvas) {
this.canvas = canvas;
....... }
private class ScaleListener extends ScaleGestureDetector.SimpleOnScaleGestureListener {
@Override
public boolean onScale(ScaleGestureDetector detector) {
canvas.save(); // here
非常に悪い習慣:/
マニフェストでAndroidハードウェアアクセラレーションを無効にしてみてください。
Android:hardwareAccelerated="false"
このようなビットマップを使用するとき、私はこのエラーを得ていました:
bmp = BitmapFactory.decodeResource(this.getResources(), R.drawable.myBitMap);
私にとっての問題を解決したのは、ビットマップのサイズを小さくすることでした(> 1000pxから700pxまで)。
私はAndroid 4.4.4でSIGSEGVに直面しました(Nexuses、Samsungs)そして、null
を使用してString
DecimalFormat
を解析することに致命的なエラーがあることがわかりました
static DecimalFormat decimalFormat = new DecimalFormat("###,###.###");
void someMethod(String value) {
...
Number number = decimalFormat.parse(value);//value is null, SIGSEGV will happen`
...
}
Android> 21ではtry/catchで正常に処理されました
あなたがビタミンライブラリを使用している場合、この致命的なエラーが発生します。
次に、プロジェクトのgradle targetSdkVersionが23未満になるようにしてください。
ありがとう。
私の場合、この問題はAndroid Profilerによって引き起こされていました。 Android Studioで、[Android Profiler]と[セッションの終了]をクリックします。
皮肉なことに、それはまたアプリケーションで極端なパフォーマンス問題を引き起こしていました。
Android.support
からandroidx
に移行した後、私は少し前にこの問題に直面しました。
問題はrenderscript
でした。
解決策:build.gradle
から次の2行を削除しました。
renderscriptTargetApi 21
renderscriptSupportModeEnabled true
未解決の参照が原因で、そのプロジェクトのビルドは失敗しました。
import androidx.renderscript.Allocation;
import androidx.renderscript.Element;
import androidx.renderscript.RenderScript;
import androidx.renderscript.ScriptIntrinsicBlur;
だから私はそれらをに変更しました:
import Android.renderscript.Allocation;
import Android.renderscript.Element;
import Android.renderscript.RenderScript;
import Android.renderscript.ScriptIntrinsicBlur;
その後、すべての問題は解決しました。
私にとってその問題は2つの活動の間の悪いキャストによるものでした。私は最近、このメソッドをActivity1から別の2に移動しました。そうすることで、リファクタリングは以前のように明示的キャストをそのままにしました。そうする代わりに
((Activity1) mainActivity).hideDialog();
私はするはずだった
((Activity2) mainActivity).hideDialog();
注:しかし、このエラーはAndroid 8.0では発生しませんでした。理由はまだわかりません。
*** それが役に立てば幸い。
JNI /ネイティブコードを確認してください。私の参照の1つはnullでしたが、それは断続的でしたので、それはあまり明白ではありませんでした。
ビルドフィンガープリント:「Motorola/harpia/harpia:6.0.1/MPIS24.241-2.50-16/16:user/release-keys」リビジョン:「p1b0」ABI:「arm」pid:18139、tid:25935、名前: GLThread 2137 >>> com.portable3d.okt.a3dmap1 <<< signal 11(SIGSEGV)、code 2(SEGV_ACCERR)、fault addr 0x7452f000
12台の携帯電話のうち2台がエラーを返し、問題がonDrawFrame()にあることがわかりました。一部のオブジェクトはnullでした。理由はわかりませんが、設定しました
if(gears==null) return;
。
onDraw()
関数内でViewTreeObserverを使用したときにこのエラーが発生しました。
@Override
protected void onDraw(Canvas canvas) {
// super.onDraw(canvas);
ViewTreeObserver vto = mTextView.getViewTreeObserver();
vto.addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
@Override
public void onGlobalLayout() {
// some animation
}
});
}
ネイティブ関数をチェックし、それが正しく返されているかどうかを調べます。返されない場合はreturnステートメントを追加してください。
メモリの問題が原因で、このセグメンテーションエラーが発生しました。私のstructは多くの変数と配列を持ち、この配列のサイズは1024でした。
サイズを512に減らすと、エラーはなくなりました。
P.S:これは回避策であり、解決策ではありません。構造体サイズを見つける必要があり、動的メモリ割り当てがより良い選択肢です。
私の場合(私はXamarin Formsを使用しています)、このエラーはバインディングエラーが原因でスローされました。 :
<Label Grid.Column="4" Grid.Row="1" VerticalTextAlignment="Start" HorizontalTextAlignment="Center" VerticalOptions="Start" HorizontalOptions="Start" FontSize="10" TextColor="Pink" Text="{Binding }"></Label>
基本的に私は誤ってビューモデルのプロパティを削除しました。 Xamarin開発者にとって、同じ問題がある場合は、バインディングを確認してください。
私のアプリ(FancyShowCaseView)に追加されたパッケージでこの問題が発生し、pre-lolipopでこの問題が発生しました。そのパッケージはkotlinで書かれており、私の主要なコードはJavaで書かれています。だから今、私はpre-lolipopでバージョンをチェックしていますが、そのクラスを実行させません。一時的に問題を解決しました。私のような似たような問題がある場合はこれをチェックしてください