Skip to content

segfault with extension dtype not defining nb_int #10693

Open
@alexhsamuel

Description

@alexhsamuel

It appears that if you create an extension type that derives PyGenericArrType and doesn't define nb_int, NumPy crashes when calling int() on an instance of your type.

This is straightforward to demonstrate with test_rational.c: replace pyrational_int with 0 on line 631 when defining nb_int. Then,

from numpy.core.test_rational import rational
r = rational(2, 3)
int(r)

This results in an infinite recursion. On OS/X, this is the bottom of the stack.

    frame #262073: 0x000000010000dfeb python`PyNumber_Long + 123
    frame #262074: 0x0000000103154c3e multiarray.cpython-36m-darwin.so`array_int + 78
    frame #262075: 0x0000000103163eba multiarray.cpython-36m-darwin.so`gentype_int + 42
    frame #262076: 0x000000010006ccd4 python`_PyLong_FromNbInt + 52
    frame #262077: 0x000000010000dfeb python`PyNumber_Long + 123
    frame #262078: 0x0000000103154c3e multiarray.cpython-36m-darwin.so`array_int + 78
    frame #262079: 0x0000000103163eba multiarray.cpython-36m-darwin.so`gentype_int + 42
    frame #262080: 0x000000010006ccd4 python`_PyLong_FromNbInt + 52
    frame #262081: 0x000000010000dfeb python`PyNumber_Long + 123
    frame #262082: 0x000000010006059b python`long_new + 139
    frame #262083: 0x00000001000b74ef python`type_call + 47
    frame #262084: 0x0000000100009df1 python`_PyObject_FastCallDict + 177
    frame #262085: 0x0000000100163348 python`call_function + 392
    frame #262086: 0x0000000100160f4c python`_PyEval_EvalFrameDefault + 47100
    frame #262087: 0x0000000100154589 python`_PyEval_EvalCodeWithName + 425
    frame #262088: 0x00000001001ac63c python`PyRun_FileExFlags + 252
    frame #262089: 0x00000001001abdee python`PyRun_SimpleFileExFlags + 366
    frame #262090: 0x00000001001d1dd6 python`Py_Main + 3718
    frame #262091: 0x0000000100001e7d python`main + 509
    frame #262092: 0x00007fff4f91c145 libdyld.dylib`start + 1
    frame #262093: 0x00007fff4f91c145 libdyld.dylib`start + 1

If the type doesn't subclass PyGenericArrType, this does not appear to occur.

Similar failure and similar stack trace on Linux/GCC/gdb.

Tested on 1.14, 1.13, 1.12 (the latter has a different stack trace) with Python 3.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions