Invalid Heap Address and Fatal Signal 11

Invalid heap address and fatal signal 11

I just ran into the same issue and had it at a re-producable state. This is the error I was getting:

08-04 17:37:05.491: A/libc(4233): @@@ ABORTING: INVALID HEAP ADDRESS IN dlfree
08-04 17:37:05.491: A/libc(4233): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)

What it boiled down to is a function call being made from two different threads at the same time.

More specifically, this function was BluetoothSocket's close() method.

I checked the source code at this website , and the call is not synchronized (not sure if this changed since it is from Android 2.1).

At any rate, do you maybe have a similar scenario where a function call is made from multiple threads? Can't say for sure from the source code you're showing.

Also have you tried not using THREAD_POOL_EXECUTOR? According to the android dev guide:

When first introduced, AsyncTasks were executed serially on a single background thread. Starting with DONUT, this was changed to a pool of threads allowing multiple tasks to operate in parallel. Starting with HONEYCOMB, tasks are executed on a single thread to avoid common application errors caused by parallel execution.

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

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.

How to solve Android Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid xxxxx (Thread-X)?

After some discussion it became clear that the problem was with interaction with memory:

extern "C" 
jdouble 
JNICALL Java_com_foo(JNIEnv *env, jclass type, jlong addrRgba, jlong addrGray) { 
  Mat &mRgb = *(Mat *) addrRgba;
  Mat &mGray = *(Mat *) addrGray;

  return (jdouble) toGray(mRgb, mGray);
}

As a quick fix double toGray(Mat& rgb, Mat& gray); had to be changed to double toGray(Mat rgb, Mat gray)

Additional information can be found on topic CvMat deep copy

---

Related Topics