10000 BUG: segfault when passing dtype module to np.array constructor · Issue #25031 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
samuelstjean opened this issue Oct 30, 2023 · 1 comment · Fixed by #25042
Closed

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

samuelstjean opened this issue Oct 30, 2023 · 1 comment · Fixed by #25042
Labels
00 - Bug 06 - Regression
Milestone
1.26.2 release

Comments

@samuelstjean
Copy link
Contributor
samuelstjean commented Oct 30, 2023 •
edited
Loading

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
Copy link
Member
ngoldbaum commented Oct 31, 2023 •
edited < A18C svg aria-hidden="true" height="16" viewBox="0 0 16 16" version="1.1" width="16" data-view-component="true" class="octicon octicon-triangle-down v-align-middle">
Loading

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.

@ngoldbaum ngoldbaum added this to the 1.26.2 release milestone Oct 31, 2023
@ngoldbaum ngoldbaum mentioned this issue Oct 31, 2023
Merged
@charris charris mentioned this issue Nov 12, 2023
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
00 - Bug 06 - Regression
Projects
None yet
Milestone
1.26.2 release
Development

Successfully merging a pull request may close this issue.

BUG: ensure passing np.dtype to itself doesn't crash ngoldbaum/numpy
2 participants
@samuelstjean @ngoldbaum
0