Invalid heap address and fatal signal 11

Question

Every so often my app will crash and my log will read:

@@@ ABORTING: INVALID HEAP ADDRESS IN dlfree
Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
<         


        

Answer 1

I had this same error yesterday. It always happened but not always consistently. What caused it for me has so far not been mentioned.

I thought I might have a similar issue because I too was dealing with threads, however I removed all my threading and the problem was still occurring. Finally after a bunch of print statements I was able to track it down to a class I had instanced which had a pointer as a private member, but I forgot to initialize the pointer.

Later when that class destructed it was trying to delete the pointer, however because the pointer was not initialized to NULL, it may or may not have some garbage value, so sometimes it would not cause a crash and other times it would. It is probably because when the garbage value was a memory location that doesn't belong to me or when it does and I delete something important, it causes the crash/error.

Here's a stripped down example of the problem I encountered:

class BadFoo
{
public:
    BadFoo() {} // BAD! We didn't initialize the pointer
    ~BadFoo() {
        if (myPtr) {
            delete myPtr;
        }
    }
    // OTHER MEMBER FUNCTIONS HERE

private:
    int* myPtr;
}

class GoodFoo
{
public:
    GoodFoo() : myPtr(NULL) {} // GOOD! Can't be garbage value now
    ~GoodFoo() {
        if (myPtr) {
            delete myPtr;
        }
    }
    // OTHER MEMBER FUNCTIONS HERE

private:
    int* myPtr;
}

Interesting to note, this crash did not occur on my Transformer Prime, but did on my Nexus4. Just goes to show we should test on multiple devices! So far the Nexus wins on helping me track down bugs as it seems to be a lot pickier.

Answer 2

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.