Main Ecosystems
HomePython CorePandas ReferenceNumPy ScientificFastAPI & PydanticDjango Enterprise
More Ecosystems
Environment & SetupRequests & HTTPAsyncIO ConcurrencyObject-Oriented OOPPyTorch Deep LearningScikit-Learn MLFlask FrameworkWeb ScrapingDatabase & ORMDevOps & Docker

Malloc Double Free Error on Apple Silicon M-Series MacBook Pro

Verified FixPython 3.10+Apple Silicon arm64Silo: environment

Quick Fix / Solution Rapide

Recreate virtual environments using native arm64 Python (arch -arm64 python3 -m venv .venv) and avoid mixing x86_64 Rosetta binaries with native arm64 dylibs.

Root Cause Analysis

This error occurs when Python or underlying native C/C++ extensions (such as PyTorch, OpenCV, or OpenMP runtimes) attempt to deallocate a heap memory block that has already been freed, triggering macOS malloc: *** error for object: pointer being freed was not allocated.

1. Mixing Rosetta (x86_64) and Native (arm64) Binaries

On Apple Silicon (M1/M2/M3/M4) Macs, running an x86_64 Python interpreter under Rosetta emulation while loading native arm64 Homebrew libraries leads to memory alignment corruption and conflicting memory allocators.

2. OpenMP Threading Conflicts (libomp vs libiomp5)

When multiple scientific packages load different OpenMP runtime libraries simultaneously (e.g. NumPy loading libomp and PyTorch loading libiomp5), conflicting thread managers double-free shared thread pool memory structures.

3. Cython Reference Counting and Memoryview Bugs

C-extensions that manually call free() on Python buffer pointers managed by Python's garbage collector create double-free conditions.

4. Fork-Safety Issues on macOS

Using multiprocessing with fork on macOS rather than spawn causes memory state duplication and corrupted heap locks in child processes.

Reproduction Code (MCVE)

Example: Bug Reproduction
# **Note de reproductibilité :** Dépendant de l'architecture matérielle (Apple Silicon M3).
raise RuntimeError('malloc: *** error for object 0x6000021c0000: pointer being freed was not allocated. Set a breakpoint in malloc_error_break to debug.')

Solution 1: Build Clean Native arm64 Virtual Environment

Ensure Python and all installed wheels are compiled for native Apple Silicon (arm64) rather than emulated x86_64.

Example: Recommended Solution
import platform
import sys

print(f'System architecture: {platform.machine()}')
print(f'Python executable: {sys.executable}')
print('Ensure architecture displays arm64. Command to rebuild:')
print('arch -arm64 python3 -m venv .venv && source .venv/bin/activate && pip install --upgrade pip wheel')

Solution 2: Set OpenMP and Multiprocessing Safe Environment Flags

Set KMP_DUPLICATE_LIB_OK=TRUE and enforce multiprocessing.set_start_method('spawn') to avoid thread allocator conflicts on macOS.

Example: Alternative Solution
import os
import multiprocessing

os.environ['KMP_DUPLICATE_LIB_OK'] = 'TRUE'
try:
    multiprocessing.set_start_method('spawn')
    print('Start method set to spawn.')
except RuntimeError:
    print('Multiprocessing context already initialized.')

A common mistake is migrating an existing virtual environment folder from an Intel Mac to an M3 Mac via Time Machine. The virtual environment remains configured with x86_64 paths and incompatible dylibs. Always delete .venv and recreate it cleanly on the new machine. Edge cases occur with terminal emulators: ensure your terminal (iTerm2 / Terminal) is NOT set to 'Open using Rosetta'. Contrast this error with Segmentation fault: 11, which occurs when accessing invalid memory addresses rather than double-freeing allocated buffers.