Android Fatal signal 11 (SIGSEGV) at 0x636f7d89 (code=1). How can it be tracked down? - Stack Overflow
Join the Stack Overflow Community
Stack Overflow is a community of 7.0 million programmers, just like you, helping each other.
J it only takes a minute:
I've been reading the other posts on tracking down the reasons for getting a SIGSEGV in an Android app. I plan to scour my app for possible NullPointers related to Canvas use, but my SIGSEGV barfs up a different memory address each time. Plus I've seen code=1 and code=2. If the memory address was 0x, I'd have a clue it is a NullPointer.
The last one I got was a code=2:
A/libc(4969): Fatal signal 11 (SIGSEGV) at 0x42a637d9 (code=2)
Any suggestions on how to track this down?
I have a suspect, but I'm not keen on experimenting with it yet. My app uses the OSMDroid API for offline mapping. The OverlayItem class represents markers/nodes on the map. I have a Service that collects data via the network to populate the OverlayItem which are then displayed on the map. In an effort to simplify my design, I extended OverlayItem into my own NodeOverlayItem class, which includes some addition attributes I use in the UI Activity and in the Service. This gave me a single point of Item information for the UI and Service. I used Intents to broadcast to the Activity to refresh the UI map when something changed. The Activity binds to the Service and there's a Service method to get the list of NodeOverlayItem's. I think it might be the OSMDroid API's use of OverlayItem, and my Service updating node information at the same time. (a concurrency issue)
As I write this I think that's really the problem. The headache isn't splitting out the Node and OverlayItem from NodeOverlayItem, it's that the Activity will need some data from the Node, that the Service holds. Plus when the Activity is created (onResume, etc...) the OverlayItem objects will need to be re-created from the Node data that the Service has been maintaining while the Activity was away. e.g. You start the app, the Service collects data, the UI displays it, you go to Home, then back to the app, the Activity will need to pull and re-create the OverlayItem's from the latest Service node data.
I know this isn't a great or clear questions. It's like all my SO questions are niche or obscure. If anyone has a suggestion on how to interpret those SIGSEGV errors, it would be greatly appreciated!
Here's the latest crash captured during a debug session. I have 3 of these devices being used for testing and they don't all crash reliably when I'm developing and testing. I included a bit extra just so the GC logging could be noted. You can see the problem is probably not related to memory exhaustion.
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 1K, 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 (4f6a83ac4936ebb3c934d) 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 (e4bc81e91ec92d06f83e) along to other nodes.
03-03 02:02:38.609: D/CommService(7477): Already processed this packet: 45ffe5e4fbf
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_A:4.0.4/MR1/eng.user.703: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
03-03 02:02:38.914: I/DEBUG(4008):
03-03 02:02:38.914: I/DEBUG(4008):
03-03 02:02:38.914: I/DEBUG(4008):
03-03 02:02:38.914: I/DEBUG(4008):
03-03 02:02:38.914: I/DEBUG(4008):
03-03 02:02:38.914: I/DEBUG(4008):
03-03 02:02:38.914: I/DEBUG(4008):
03-03 02:02:38.914: I/DEBUG(4008):
03-03 02:02:38.914: I/DEBUG(4008):
d16 3fe62e42fefa39ef
03-03 02:02:38.914: I/DEBUG(4008):
d18 3fe62e42fee00000
03-03 02:02:38.914: I/DEBUG(4008):
03-03 02:02:38.914: I/DEBUG(4008):
03-03 02:02:38.914: I/DEBUG(4008):
03-03 02:02:38.914: I/DEBUG(4008):
03-03 02:02:38.914: I/DEBUG(4008):
03-03 02:02:38.914: I/DEBUG(4008):
d31 3fecccccb5c28f6e
03-03 02:02:38.914: I/DEBUG(4008):
03-03 02:02:39.046: I/DEBUG(4008):
/system/lib/libcrypto.so (EVP_DigestFinal_ex)
03-03 02:02:39.046: I/DEBUG(4008):
/system/lib/libcrypto.so (EVP_DigestFinal)
03-03 02:02:39.054: I/DEBUG(4008):
/system/lib/libnativehelper.so
03-03 02:02:39.054: I/DEBUG(4008):
pc 0001ec30
/system/lib/libdvm.so (dvmPlatformInvoke)
03-03 02:02:39.054: I/DEBUG(4008):
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): 402de ff460d 4620ff81
....p..F.F.... F
03-03 02:02:39.054: I/DEBUG(4008): 402d29 bd70ff93 e6800
)F....p.p..F.h.F
03-03 02:02:39.054: I/DEBUG(4008): 402d5 dd062b40 21faa10
.F.h@+...H.!.JxD
03-03 02:02:39.054: I/DEBUG(4008): 402d7a 8a1
zD....!h F.i1F.G
03-03 02:02:39.054: I/DEBUG(4008): 402d01a0 b2b 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 68ec4a ea0af7c4 bd704630
!h.hJl.!....0Fp.
03-03 02:02:39.054: I/DEBUG(4008): 402d01cc 314b5
........p..F....
03-03 02:02:39.054: I/DEBUG(4008): 402d01dc
ff12f7ff bd4b573
.F F....(Fp.s..F
03-03 02:02:39.054: I/DEBUG(4008): 402d01ec 2102460d fb36f002 42ab0
.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): 4d8cc4000
03-03 02:02:39.054: I/DEBUG(4008): (no map for address)
03-03 02:02:39.054: I/DEBUG(4008): b09000 /system/bin/linker
03-03 02:02:39.054: I/DEBUG(4008): stack:
03-03 02:02:39.054: I/DEBUG(4008):
/system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008):
/dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008):
03-03 02:02:39.054: I/DEBUG(4008):
/system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008):
/system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008):
03-03 02:02:39.054: I/DEBUG(4008):
/system/framework/core.odex
03-03 02:02:39.054: I/DEBUG(4008):
/system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008):
/dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008):
03-03 02:02:39.054: I/DEBUG(4008):
/dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008):
03-03 02:02:39.054: I/DEBUG(4008):
/dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008):
03-03 02:02:39.054: I/DEBUG(4008):
03-03 02:02:39.054: I/DEBUG(4008):
03-03 02:02:39.054: I/DEBUG(4008): #00 4d9c3bc8
03-03 02:02:39.054: I/DEBUG(4008):
03-03 02:02:39.054: I/DEBUG(4008):
03-03 02:02:39.054: I/DEBUG(4008):
/system/lib/libcrypto.so
03-03 02:02:39.054: I/DEBUG(4008): #01 4d9c3bd8
03-03 02:02:39.054: I/DEBUG(4008):
03-03 02:02:39.054: I/DEBUG(4008):
03-03 02:02:39.054: I/DEBUG(4008):
/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 1K, paused 51ms
03-03 02:02:39.632: D/dalvikvm(7477): GC_CONCURRENT freed 1998K, 16% free 1K, 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 1K, 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 1K, 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 1K, paused 3ms+4ms
03-03 02:02:42.679: D/dalvikvm(7477): GC_CONCURRENT freed 2006K, 16% free 1K, 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 1K, paused 62ms
03-03 02:02:43.265: D/dalvikvm(1236): GC_FOR_ALLOC freed 243K, 16% free 1K, paused 49ms
03-03 02:02:43.265: I/dalvikvm-heap(1236): Grow heap (frag case) to 10.507MB for 196628-byte allocation
2,55453364
1,79452447
First, get your tombstone stack trace, it will be printed every time your app crashes. Something like this:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'XXXXXXXXX'
pid: 1658, tid: 13086
&&& system_server &&&
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 64696f7e
r2 ad12d1e8
r3 7373654d
r4 64696f72
r7 40d14008
r8 4b857b88
r9 4685adb4
fp 4b857ed8
sp 4b857b50
lr afd11108
pc ad115ebc
00e81fe04b1b64d8
/system/lib/libc.so
pc 0003724c
/system/lib/libxvi020.so
pc 0000ce02
/system/lib/libxvi020.so
/system/lib/libxvi020.so
pc 00010cce
/system/lib/libxvi020.so
/system/lib/libwimax_jni.so
pc 00011e74
/system/lib/libdvm.so
pc 0004354a
/system/lib/libdvm.so
/system/lib/libdvm.so
/system/lib/libdvm.so
/system/lib/libdvm.so
pc 00059c24
/system/lib/libdvm.so
pc 00059e3c
/system/lib/libdvm.so
pc 0004e19e
/system/lib/libdvm.so
pc 00011b94
/system/lib/libc.so
pc 0001173c
/system/lib/libc.so
code around pc:
ad115e9c 4620eddc bf00bd70 01734e
ad115eac c4c0a f7f4edc8
ad115ebc 42ab68e3 68a0d103 f7fedd2
ad115ecc d1f52c00
edbef7f4 bf00bd70
ad115edc b51f
code around lr:
afd110e8 ea404
afd110f8 ea01 ebffed92
afd10 a000001 ea000009
afd11118 ebfffe50 e1a006 ebffed92
afd105 ea000
/system/lib/libnativehelper.so
Then, use the addr2line utility (find it in your NDK tool-chain) to find the function that crashes. In this sample, you do
addr2line -e -f libc.so 0001173c
And you will see where you got the problem. Of course this wont help you since it is in libc.
So you might combine the utilities of arm-eabi-objdump to find the final target.
Believe me, it is a tough task.
Just for an update. I think I was doing Android native build from the whole-source-tree for quite a long time, until today I have myself carefully read the NDK documents. Ever since the release NDK-r6, it has provided a utility called ndk-stack.
Following is the content from official NDK documents with the NDK-r9 tar ball.
ndk-stack is a simple tool that allows you to filter stack traces as they appear in the output of 'adb logcat' and replace any address inside a shared library with the corresponding : values.
In a nutshell, it will translate something like:
31): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
31): Build fingerprint: 'generic/google_sdk/generic/:2.2/FRF91/43546:eng/test-keys'
31): pid: 351, tid: 351
%%% /data/local/ndk-tests/crasher &&&
31): signal 11 (SIGSEGV), fault addr 0d9f00d8
r0 0000af88
r2 baadf00d
r3 0d9f00d8
r6 0000af88
r7 00013c44
ip 0000959c
sp be956cc8
pc 0000841e
pc 0000841e
/data/local/ndk-tests/crasher
pc 000083fe
/data/local/ndk-tests/crasher
/data/local/ndk-tests/crasher
pc 000191ac
/system/lib/libc.so
pc 000083ea
/data/local/ndk-tests/crasher
/data/local/ndk-tests/crasher
/system/lib/libc.so
Into the more readable output:
********** 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
/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
/data/local/ndk-tests/crasher : Routine main in /tmp/foo/crasher/jni/main.c:19
Stack frame #06
/system/lib/libc.so
To do this, you will first need a directory containing symbolic versions of your application's shared libraries. If you use the NDK build system (i.e. ndk-build), then these are always located under $PROJECT_PATH/obj/local/, where
stands for your device's ABI (i.e. armeabi by default).
You can feed the logcat text either as direct input to the program, e.g.:
adb logcat | $NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi
Or you can use the -dump option to specify the logcat as an input file, e.g.:
adb logcat & /tmp/foo.txt
$NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi -dump foo.txt
IMPORTANT :
The tool looks for the initial line containing starts in the logcat output, i.e. something that looks like:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
When copy/pasting traces, don't forget this line from the traces, or ndk-stack won't work correctly.
A future version of ndk-stack will try to launch adb logcat and select the library path automatically. For now, you'll have to do these steps manually.
As of now, ndk-stack doesn't handle libraries that don't have debug information in them. It may be useful to try to detect the nearest function entry point to a given PC address (e.g. as in the libc.so example above).
2,55453364
5,32921431
OK! I'm really sorry to those that have actually submitted comments and answers, but I found the problem. I don't think this will help a lot of others trying to track down their personal SIGSEGV, but mine (and it was very hard) was entirely related to this:
The libcrypto.so in my dump kind of clued me in. I do a MD5 hash of packet data when trying to determine if I've already seen the packet, and skipping it if I had. I thought at one point this was an ugly threading issue related to tracking those hashes, but it turned out it was the java.security.MessageDigest class! It's not thread safe!
I swapped it out with a UID I was stuffing in every packet based on the device UUID and a timestamp. No problems since.
I guess the lesson I can impart to those that were in my situation is, even if you're a 100% Java application, pay attention to the native library and symbol noted in the crash dump for clues. Googling for SIGSEGV + the lib .so name will go a lot farther than the useless code=1, etc... Next think about where your Java app could touch native code, even if it's nothing you're doing. I made the mistake of assuming it was a Service + UI threading issue where the Canvas was drawing something that was null, (the most common case I Googled on SIGSEGV) and ignored the possibility it could have been completely related to code I wrote that was related to the lib .so in the crash dump. Naturally java.security would use a native component in libcrypto.so for speed, so once I clued in, I Googled for Android + SIGSEGV + libcrypto.so and found the documented issue. Good luck!
1,79452447
I also got this error many times and I solved it.
This error will be faced in case of memory management in native side.
Your application is accessing memory outside of its address space. This is most likely an invalid pointer access. SIGSEGV = segmentation fault in native code. Since it is not occurring in Java code you won't see a stack trace with details. However, you may still see some stack trace information in the logcat if you look around a bit after the application process crashes. It will not tell you the line number within the file, but will tell you which object files and addresses were in use in the call chain. From there you can often figure out which area of the code is problematic. You can also setup a gdb native connection to the target process and catch it in the debugger.
I was getting this error by saving an object to the shared preferences as a gson converted string. The gson String was no good, so retrieving and deserializing the object was not actually working correctly. This meant any subsequent accesses to the object resulted in this error. Scary :)
4,04652950
I was getting this error when using a bitmap like this:
bmp = BitmapFactory.decodeResource(this.getResources(), R.drawable.myBitMap);
What fixed the problem for me was to reduce the size of the bitmap (>1000px high to 700px).
I've faced with SIGSEGV on Android 4.4.4 (Nexuses, Samsungs)
And it turned out that fatal error was in parsing null String using DecimalFormat
static DecimalFormat decimalFormat = new DecimalFormat("###,###.###");
void someMethod(String value) {
Number number = decimalFormat.parse(value);//value is null, SIGSEGV will happen`
On Android > 21 it was handled successfully with try/catch
1,67111015
Well I was facing this issue, I clearly could not figure out what was the reason. but Before this issue I was facing google ads issue. When I solved that than app was just crashing right after app was displayed.
I just uninstalled the application. Then When I have ran the application again it was working fine.
I've encountered this error when I tried to access the 'canvas' outside of onDraw()
protected void onDraw(Canvas canvas) {
this.canvas =
private class ScaleListener extends ScaleGestureDetector.SimpleOnScaleGestureListener {
public boolean onScale(ScaleGestureDetector detector) {
canvas.save(); // here
A very bad practice :/
Your Answer
Sign up or
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Post as a guest
By posting your answer, you agree to the
Not the answer you're looking for?
Browse other questions tagged
rev .25686
Stack Overflow works best with JavaScript enabled