Android Fatal signal 11 (SIGSEGV) at 0x636f7d89 (code=1). How can it be tracked down?

Question

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 relate

Answer 1

In my case the issue was being caused by the Android Profiler. In Android Studio, click on "Android Profiler" and "end session".

Ironically, it was also causing extreme performance issues in the application.

Answer 2

I've encountered this error when I tried to access the 'canvas' outside of 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

A very bad practice :/

Answer 3

I faced this issue moment ago, after migrating from android.support to androidx.

The problem was renderscript.

Solution: I removed from my build.gradle those two lines:

renderscriptTargetApi 21
renderscriptSupportModeEnabled true

after that project building failed, because of unresolved references:

import androidx.renderscript.Allocation;
import androidx.renderscript.Element;
import androidx.renderscript.RenderScript;
import androidx.renderscript.ScriptIntrinsicBlur;

so I've changed them to:

import android.renderscript.Allocation;
import android.renderscript.Element;
import android.renderscript.RenderScript;
import android.renderscript.ScriptIntrinsicBlur;

After that all problems were gone.

Answer 4

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:

https://code.google.com/p/android/issues/detail?id=8709

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!

Answer 5

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).

Answer 6

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