Closed inakleinbottle closed 1 week ago
Maybe a stack overflow!? Since NumPy indicates recursion correctly, I am not sure why that would happen (Py 3.12 might have changes with recursion/stack overflow avoidance.).
But who knows, maybe there is also just something subtly wrong.
Can you put the test into a file.py
:
import numpy as np
d = dict(names=['self'], formats=[None], offsets=[0])
d['formats'][0] = d
np.dtype(d)
and run it with spin gdb file.py
. Then r
(to run) and bt
(backtrace) once it crashed and report the backtrace?
Dunno if it will be helpful, but worth a shot (you need gdb installed of course).
Python makes a best effort to raise RecursionError before crashing, but sometimes the heuristics go awry. Debug builds mess with the heuristics, and I am not surprised it goes wrong somewhere. I will close this, please reopen or open a new issue if you have a fix we could do to the test to better catch the recursion.
Describe the issue:
The nested dictionary dtype construction does not throw a RecursionError as expected in the test, and instead causes a segmentation fault. Since this is happening on a source build, I don't know if it is something that I have done to misconfigure the build, I just used
spin build -- -Dbuildtype=debug
andspin test
.Reproduce the code example:
Error message:
Python and NumPy Versions:
Python 3.12.4 numpy main head: SHA256
2093a6d5b933f812d15a3de0eafeeb23c61f948a
built with debug configuration, using MKL for blas/lapack (thought I don't know why that would make any difference).Runtime Environment:
No response
Context for the issue:
No response