BUG: SIGSEGV when creating an array from a deeply nested structured dtype

Describe the issue:

Creating an array from a sufficiently deeply nested structured dtype can terminate the Python process with SIGSEGV instead of raising a catchable exception.

The structured dtype itself can be constructed successfully at very large nesting depths. The crash occurs when the dtype is subsequently used to create an array, for example with numpy.zeros().

On my test system with NumPy 2.5.2, the crash occurs at approximately 43,000+ levels of nested structured dtype. The exact threshold is environment-dependent.

The same behavior was also reproduced with NumPy 2.4.4.

I also tested the .npy loading path with a crafted header describing the same nested dtype. With the default max_header_size=10000, numpy.load() rejected the oversized header before reaching the crashing path on my tested configuration.

Reproduce the code example:

import numpy as np

depth = 44000

dt = np.dtype([("v", "i4")])

for _ in range(depth):
    dt = np.dtype([
        ("v", "i4"),
        ("next", dt),
    ])

print("dtype constructed successfully")
print("dtype itemsize:", dt.itemsize)

# SIGSEGV on my test system
arr = np.zeros(1, dtype=dt)

print("array constructed successfully")

Error message:

The process terminates with `SIGSEGV` and does not raise a Python-level exception.

Observed output:


dtype constructed successfully
dtype itemsize: 176004
Segmentation fault (core dumped)


### GDB reports:

Thread 1 "python" received signal SIGSEGV, Segmentation fault.

Relevant portion of the GDB backtrace:


#43646 0x00007ffff6b9c8c8 in PyArray_NewFromDescr_int ()
   from /tmp/numpy-poc-venv/lib/python3.12/site-packages/numpy/_core/_multiarray_umath.cpython-312-x86_64-linux-gnu.so
#43647 0x00007ffff6b9e8cb in PyArray_Zeros_int ()
   from /tmp/numpy-poc-venv/lib/python3.12/site-packages/numpy/_core/_multiarray_umath.cpython-312-x86_64-linux-gnu.so
#43648 0x00007ffff6bf8c0d in array_zeros ()
   from /tmp/numpy-poc-venv/lib/python3.12/site-packages/numpy/_core/_multiarray_umath.cpython-312-x86_64-linux-gnu.so
#43649 0x0000000000581dad in ?? ()
#43650 0x0000000000549835 in PyObject_Vectorcall ()
#43651 0x00000000005d7429 in _PyEval_EvalFrameDefault ()
...
#43661 0x0000000000658345 in _start ()

Python and NumPy Versions:

2.5.2
3.12.3 (main, Jul 15 2026, 23:46:41) [GCC 13.3.0]

Tested and reproduced on:

• NumPy 2.5.2
• Python 3.12.3
• x86-64 Linux
• glibc 2.39
• Linux 7.0.0-30-generic

The same crash was also independently reproduced with NumPy 2.4.4 on the same general environment.

Runtime Environment:

[{'numpy_version': '2.5.2',
  'python': '3.12.3 (main, Jul 15 2026, 23:46:41) [GCC 13.3.0]',
  'uname': uname_result(system='Linux', node='ubuntu', release='7.0.0-30-generic', version='#30~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug  7 13:27:52 UTC 2', machine='x86_64')},
 {'simd_extensions': {'baseline': ['X86_V2'],
                      'found': ['X86_V3'],
                      'not_found': ['X86_V4', 'AVX512_ICL', 'AVX512_SPR']}},
 {'ignore_floating_point_errors_in_matmul': False},
 {'architecture': 'Haswell',
  'filepath': '/tmp/numpy-poc-venv/lib/python3.12/site-packages/numpy.libs/libscipy_openblas64_-61654e39.so',
  'internal_api': 'openblas',
  'num_threads': 16,
  'prefix': 'libscipy_openblas',
  'threading_layer': 'pthreads',
  'user_api': 'blas',
  'version': '0.3.34.0.0'}]

How does this issue affect you or how did you find it:

I found this issue as part of ongoing research into uncontrolled recursion, resource consumption, and process-crashing conditions in data-processing and serialization libraries.

I have reported close to 15 bugs involving uncontrolled recursion, denial of service, and process crashes across different libraries and software components. This work is also directly related to our published USENIX WOOT '26 paper:

“Evading and crashing anti-malware solutions via data collection overloading during analysis serialization”

by Evgenios Gkritsis, Constantinos Patsakis, and George Stergiopoulos.

In that work, we introduce Telemetry Complexity Attacks (TCAs), which demonstrate how adversarially generated deeply nested or oversized data can stress serialization, storage, and visualization components in malware analysis and EDR systems, potentially resulting in denial-of-analysis conditions.

This NumPy issue follows the same broader research direction: examining how deeply nested data structures can cross recursion or resource boundaries and cause uncontrolled behavior. In this case, a valid deeply nested structured dtype can exhaust the native call stack during array construction and terminate the Python process with SIGSEGV.

I am reporting it because the behavior is an unrecoverable native crash where a controlled exception or explicit depth/resource limit would be preferable.

Reproduce the crash with the deeply nested dtype example and inspect the array-construction path around PyArray_NewFromDescr_int and PyArray_Zeros_int. Trace how numpy.zeros handles nested structured dtypes, then add coverage for this depth case; done means it no longer terminates Python with SIGSEGV and instead produces a catchable failure or completes safely.