BUG: segfault when passing dtype module to np.array constructor

[samuelstjean]

Describe the issue:

Passing nonsense to np.array can crash the whole intepreter.

Reproduce the code example:

#this works 
np.array(np.ones(10), dtype=None)

#this also makes a sensible error because it is nonsense
np.array(np.ones(10), dtype=np.linalg)

TypeError: Cannot interpret '<module 'numpy.linalg' from '/home/samuel/miniconda3/envs/py310/lib/python3.10/site-packages/numpy/linalg/__init__.py'>' as a data type

# this will happily segfault and kick you out of your program, while it should probably do the same as above instead
np.array(np.ones(10), dtype=np.dtype)

Error message:

Segfault message, or untranslated 

In [10]: np.array(np.ones(10), dtype=np.dtype)
fish : Tâche Tâche 1,, 'bash -c 'ipython --pylab' $argv' terminée par le signal SIGSEGV (Erreur de frontière d'adresse)

Runtime information:

1.26.1
3.10.0 (default, Mar 3 2022, 09:58:08) [GCC 7.5.0]

In [1]: print(numpy.show_runtime())
[{'numpy_version': '1.26.1',
'python': '3.10.0 (default, Mar 3 2022, 09:58:08) [GCC 7.5.0]',
'uname': uname_result(system='Linux', node='samuel-dmri', release='5.15.0-87-generic', version='#97~20.04.1-Ubuntu SMP Thu Oct 5 08:25:28 UTC 2023', machine='x86_64')},
{'simd_extensions': {'baseline': ['SSE', 'SSE2', 'SSE3'],
'found': ['SSSE3',
'SSE41',
'POPCNT',
'SSE42',
'AVX',
'F16C',
'FMA3',
'AVX2'],
'not_found': ['AVX512F',
'AVX512CD',
'AVX512_KNL',
'AVX512_KNM',
'AVX512_SKX',
'AVX512_CLX',
'AVX512_CNL',
'AVX512_ICL']}},
{'architecture': 'Haswell',
'filepath': '/home/samuel/miniconda3/envs/py310/lib/python3.10/site-packages/numpy.libs/libopenblas64_p-r0-0cf96a72.3.23.dev.so',
'internal_api': 'openblas',
'num_threads': 16,
'prefix': 'libopenblas',
'threading_layer': 'pthreads',
'user_api': 'blas',
'version': '0.3.23.dev'}]
None

Context for the issue:

Nothing bad, but it should probably just raise an error instead of crashing completely.

Not sure a traceback with gdb would be needed since it does not seems to be to obscure at first and easy to reproduce. I'd guess the np.dtype function/object just falls into the crack when you do not specify any dtype.

[ngoldbaum]

Thank you for the report! I can reproduce this and get the following location for the seg fault:

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
0x00007ffff65aa0de in PyArray_CastDescrToDType (descr=0x7ffff6b5f400 <DOUBLE_Descr>, given_DType=0x7ffff6b6a2a0 <PyArrayDescr_TypeFull>) at ../numpy/_core/src/multiarray/convert_datatype.c:1107
1107	        return NPY_DT_CALL_default_descr(given_DType);
(gdb) p given_DType
$1 = (PyArray_DTypeMeta *) 0x7ffff6b6a2a0 <PyArrayDescr_TypeFull>
(gdb) p (NPY_DType_Slots *)(given_DType)->dt_slots
$2 = (NPY_DType_Slots *) 0x0

The issue is np.dtype isn't a module, it's an instance of the dtype metaclass:

In [2]: type(np.dtype)
Out[2]: numpy._DTypeMeta

And we have special handling so that you can do something like np.dtype(type(some_dtype)). In the past it wouldn't be very natural to do something like that but it becomes a lot more natural with the introduction of the np.dtypes namespace, which lets you do things like np.dtype(np.dtypes.Int64DType), which is equivalent to np.dtype('int64').

The fix here is to account for this corner case in the dtype creation internals.