使用NDK开发Android代码时遇heap corruption崩溃，求解决方案

Hey there, let's dig into this heap corruption crash you're facing when calling malloc in your Android NDK code. That A/libc: heap corruption detected by dlfree error followed by a SIGABRT (signal 6) is a clear sign your code is messing up the heap structure—most likely from writing outside allocated memory bounds, double-freeing pointers, or using a pointer after it's been freed. Here's how to track down and fix this:

This is the most common culprit. If you allocate N bytes with malloc but write more than N bytes to that memory, you'll corrupt the heap's internal metadata, which triggers the dlfree check later.

For example, this code is a ticking time bomb:

// Allocate 10 bytes
char* buffer = (char*)malloc(10);
// Copy a string that's 15 bytes long—this writes beyond the allocated buffer
strcpy(buffer, "Hello, Android!");

Fixes:

• Use safer string functions like strncpy (remember to add a null terminator) or calculate the exact required size before allocation:

  const char* my_str = "Hello, Android!";
  char* buffer = (char*)malloc(strlen(my_str) + 1); // +1 for null terminator
  if (buffer != NULL) {
      strcpy(buffer, my_str);
  }
  

• Always validate that any writes (including array indexing) stay within the allocated memory range.

These are equally common and just as destructive:

• Double-free: Calling free on the same pointer twice. The first free returns memory to the heap; the second tries to free already deallocated memory, corrupting the heap.

  int* data = (int*)malloc(sizeof(int));
  free(data);
  free(data); // Boom—double-free here
  

• Use-after-free: Accessing memory after it's been freed. Even a single write to freed memory can mess up the heap's structure.

  char* temp = (char*)malloc(20);
  free(temp);
  strcpy(temp, "Oops"); // Using a freed pointer
  

Fixes:

• After calling free, immediately set the pointer to NULL. This way, if you accidentally try to use it again, you'll get a crash faster (which is easier to debug than heap corruption):

  free(data);
  data = NULL;
  

• Add debug logs to track pointer lifecycle—log when you allocate, use, and free pointers to spot inconsistencies.

The Android NDK has a powerful tool called AddressSanitizer that will pinpoint exactly where the heap corruption happens. It's a game-changer for these kinds of bugs.

To enable it in your CMake project:

# Add these lines to your CMakeLists.txt
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fsanitize=address -fno-omit-frame-pointer")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fsanitize=address -fno-omit-frame-pointer")
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fsanitize=address")

When you run your app with ASAN enabled, it will crash at the exact line that causes the heap corruption (not later when dlfree detects it) and show a detailed stack trace with the problematic code.

While rare on Android, malloc can return NULL if the system is out of memory. If you try to write to a NULL pointer, you'll cause undefined behavior that might manifest as heap corruption. Always check the return value:

size_t required_size = 1024;
char* buffer = (char*)malloc(required_size);
if (buffer == NULL) {
    // Handle allocation failure—log an error and exit gracefully
    __android_log_print(ANDROID_LOG_ERROR, "NDK", "Failed to allocate %zu bytes", required_size);
    return;
}

Some operations (like SIMD instructions or hardware-specific code) require memory to be aligned to a certain byte boundary. Using malloc might not guarantee the required alignment, leading to subtle heap corruption.

If you need aligned memory, use posix_memalign instead:

void* aligned_buffer;
// Request 16-byte aligned memory, 1024 bytes total
int result = posix_memalign(&aligned_buffer, 16, 1024);
if (result != 0) {
    __android_log_print(ANDROID_LOG_ERROR, "NDK", "Aligned allocation failed");
    return;
}
// Use aligned_buffer...
free(aligned_buffer); // Still use free to deallocate

If your code uses pointer arithmetic (e.g., buffer + offset), make sure the calculated offset doesn't exceed the allocated memory size. For example:

// Allocate 5 integers (indices 0-4)
int* numbers = (int*)malloc(5 * sizeof(int));
// This writes to the 6th integer—way outside the allocated buffer
numbers[5] = 42;

Double-check all array indices and pointer offsets to ensure they stay within bounds.

内容的提问来源于stack exchange，提问作者Android Learner