CODEWITHSUNDEEP
androidsegmentation-fault
Nrupatunga
Nrupatunga

Reputation: 489

Cannot Debug I/DEBUG(187): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000004

I'm working on an android application which needs lot of memory allocations(Lot of image buffers). I am using Android NDK for that. I am coming across a weird crashes. I hope this is not repeated post (after going through previous posts)

The app crashes with following error: I/DEBUG(187): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000004

  1. I have come across segmentation error before and have solved it.

  2. I am pretty sure that I am allocating and deallocating the memory properly, because I have same set up for windows which confirms that there are no memory leaks and I am not accessing any location which is not allocated. (No derefrencing, no bad pointers). No memory corruptions were found while testing on windows.

  3. Im also sure that JNI calls made for allocations and deallocations are at proper place in the code. Memory are cleared only when the usage is done.

  4. Backtrace shows different API calls each time the crash occurs, where the error is happening. I have taken logs and none of the pointers are null and they are as expected.

  5. This crash occurs very randomly. Once in a while. a. When i m inside the app for long time. b. when lot of actions are performed inside the app. But it works well most of the time.

Can anyone suggest how the memory is getting corrupted in my code. what might be causing this.

Upvotes: 3

Views: 17866

Answers (3)

Edgehog.net
Edgehog.net

Reputation: 356

fault addr 00000004 => means stack was corrupted(very close to 0 addr).

This is an example how you can easily replicate this error be accidentally dereferencing a string like this:

int a = foo();
LOGE("Foo() is %d", a ? "ok" : "not ok");

it should be "%s" and not "%d"

Hope it helps to someone.

Upvotes: 1

Leonardo
Leonardo

Reputation: 1864

Check for places where you might be acessing a field from a struct or from an array. The reason I say this is because the faulty address is 00000004, which is 4 bytes after a NULL address. Check for every field access, specially in code that is performed a lot of times. Also, check for NULL returns from malloc/new, your device might be out of memory.

Since you said this problem occurs when there's a lot of actions performed or when the app is left running for a long time, I'd check for memmory leaks. Your app might be the one consuming all of the device memory. If you have custom allocators/deallocators, you might want to use a global counter, for every allocation you increase it, for every deallocation, decrease it. If the counter gets too hight, its a memmory leak.

Upvotes: 6

Devolus
Devolus

Reputation: 22094

A random position of the crash often happens when the stack is corrupted, so you should look carefully for your local variables. For example, overwriting an array of length N with M or something like this.

Upvotes: 2

Related Questions