Qiskit Transpiler malloc: Heap corruption detected crash

[epelofske-LANL]

Environment

• Qiskit version: qiskit==2.2.1
• Python version: 3.14.0
• Operating system: MacOS

What is happening?

Compiling a circuit in Qiskit using Transpile() calls results in a malloc: Heap corruption detected error.

How can we reproduce the issue?

I think this error does not happen deterministically at all. I have found it once out of 1 million transpile() calls to complex quantum circuits. So it also happens rarely. But no single circuit or set of transpiler settings deterministically induces this error.

What should happen?

The code will crash, at the transpile() call with an error that looks like this:

python3(84162,0x1f53ce0c0) malloc: Heap corruption detected, free list is damaged at 0x600002d07fc0
*** Incorrect guard value: 162876951461043
python3(84162,0x1f53ce0c0) malloc: *** set a breakpoint in malloc_error_break to debug
zsh: abort 

Any suggestions?

No response

[jakelishman]

Thanks for the report - I guess the chance of us being able to track it down if it's so uncommon and so stochastic feels pretty slim, but interesting to know it's happening.

Are you able to reproduce with any Python other than 3.14? I wonder if there's any chance it's a Python bug, or PyO3 0.26 not interacting properly with Python 3.14 (we only use the stable API, so it should be ok). I'll handle the PyO3 0.27 update soon - it just released yesterday - which is explicitly tested against 3.14.

Which macOS version are you running, and Intel or ARM Mac?

[epelofske-LANL]

Yes, I have seen this behavior from earlier python versions as well as earlier qiskit versions to varying degrees. But, reproducing this specific error at this qiskit version is very hard because of the scale required, so I do not have any rigorous stats or info on earlier python versions for qiskit 2.2.

Macos 15.6.1. ARM, not intel.

[jakelishman]

Ah ok, if it existed on previous Python versions, then something's very curious. It's usually really pretty tricky for us to have heap-corruption bugs given we're using Rust rather than raw C/C++, but it's certainly not impossible. Possibly the next bet is something to do with calls to linalg libraries somewhere in our stack. It's definitely good to keep on eye out for this - thanks for the report.

[epelofske-LANL]

Yep. I have managed to replicate it only a handful of more times. Seems to happen for dense circuits, compiling to sparse geometries like the heavy-hex.

python3(12324,0x1f53ce0c0) malloc: Heap corruption detected, free list is damaged at 0x600002b43fc0
*** Incorrect guard value: 68201577856324
python3(12324,0x1f53ce0c0) malloc: *** set a breakpoint in malloc_error_break to debug

Are there any debug settings I can turn on to print more info when this happens?

[epelofske-LANL]

Unclear if this is directly related or not, but I just ran into a segmentation fault from this same set of compilation runs I am doing. No other debug info was printed to standard output other than segmentation fault.

[jakelishman]

Are you able to share anything about the particular circuits and compilations?

We're trying to set off an ARM Mac to just run stuff in a big loop in a debugger. A segfault might be able to tell us more, if you're able to generate a core dump file and share it with us.

[epelofske-LANL]

The transpile call is really just left to default settings. I am supplying a basis gateset, and a connectivity layout. The circuits are very dense, I think this problem gets triggered with large random circuits (e.g. large quantum volume, RCS, circuits). I am compiling to all of the current IBM backends - e.g. brisbane, kingston, fez, torino, etc.

I do not know how to pull out a coredump from these runs... I guess I may be able to get it from a python pid?

[mtreinish]

I've been running the following script for >40 hrs on an arm64 macbook with macOS 26.0.1 (with accelerate version 1.11) with Python 3.14 installed from the official packages on python.org under lldb with the breakpoint set as suggested by the error message in the OP and have yet to have any issues reported with heap corruption or encounter any segfaults:

import qiskit
from qiskit.circuit.random import random_circuit


def main():
    target = qiskit.transpiler.Target.from_configuration(["rz", "sx", "x", "cz", "id", "measure"], coupling_map=qiskit.transpiler.CouplingMap.from_heavy_hex(9))
    pm = qiskit.transpiler.generate_preset_pass_manager(target)
    for i in range(10_000_000):
        qc = random_circuit(120, 120, seed=i)
        qc.measure_all()
        tqc = pm.run(qc)
        print(f"Run i: {tqc.count_ops()}")

if __name__ == "__main__":
    main()

I just restarted it changing the random_circuit() call with a quantum_volume(130, 130) circuit and replacing the reused pass manager with a transpile() call in each loop iteration. I'll keep it running it under a debugger to try and reproduce it. But I am thinking this could equally be an issue with your local environment or a hardware issue as well. These errors could easily be caused by a bug in a system library, a compiler bug when Python was built, or also failing RAM or other hardware issues. If you're able to reproduce it reliably locally could you also try running the process under a debugger and set the breakpoint as suggested by the error message to see what the backtrace is on malloc error.

As for the core dumps I'm not super familiar with macOS, but there is a /cores directory that I think macOS uses for core dumps when a program crashes. It should populate the core dump in there when your program crashed with a segfault if it generated a core dump.

[epelofske-LANL]

Could be my env for sure. The hardware is quite new, so that would be surprising. I have noticed most of the crashes happen, I think with ECR gates -- e.g. compiling to brisbane for example. But this is far from a trend. I have a sample size of something like 6 crashes in total at the moment. This is the transpile call I am using: transpile(circuit, optimization_level=3, coupling_map = coupling_map, basis_gates=basis_gates_list), where coupling_map is from one of the currently online IBM processors, same with basis gates list.