Numpy: Fallo en `np.vdot` para un objeto similar a una matriz

Creado en 10 ago. 2019 · 6Comentarios · Fuente: numpy/numpy

numpy.vdot puede segregarse si se pasa un objeto que implementa __array__ de una manera no estándar.

El segfault ocurre en esta línea de código:
https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/multiarraymodule.c#L2245
ya que type puede ser NULL si PyArray_DescrFromType falla.

Ejemplo de código de reproducción:

import numpy as np

class Foo(object):
     def __array__(self, a):
         return self

np.vdot(Foo(), Foo())

Mensaje de error:

Traza atrás:

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x0000000100cef88e _multiarray_umath.cpython-37m-darwin.so`array_vdot + 126
    frame #1: 0x00000001005e0994 python`PyCFunction_Call + 148
    frame #2: 0x0000000100c48dc1 _multiarray_umath.cpython-37m-darwin.so`array_implement_array_function + 305
    frame #3: 0x00000001005e11b3 python`_PyMethodDef_RawFastCallKeywords + 227
    frame #4: 0x00000001005e071c python`_PyCFunction_FastCallKeywords + 44
    frame #5: 0x00000001006b6048 python`call_function + 664
    frame #6: 0x00000001006b2a18 python`_PyEval_EvalFrameDefault + 27080
    frame #7: 0x00000001006b6e45 python`_PyEval_EvalCodeWithName + 2997
    frame #8: 0x00000001005e06d6 python`_PyFunction_FastCallKeywords + 230
    frame #9: 0x00000001006b60d9 python`call_function + 809
    frame #10: 0x00000001006b2987 python`_PyEval_EvalFrameDefault + 26935
    frame #11: 0x00000001006b6e45 python`_PyEval_EvalCodeWithName + 2997
    frame #12: 0x00000001006abfb0 python`PyEval_EvalCode + 48
    frame #13: 0x00000001006ee677 python`PyRun_InteractiveOneObjectEx + 615
    frame #14: 0x00000001006ede4e python`PyRun_InteractiveLoopFlags + 190
    frame #15: 0x00000001006edd5c python`PyRun_AnyFileExFlags + 60
    frame #16: 0x0000000100710c51 python`pymain_main + 7873
    frame #17: 0x000000010071127f python`_Py_UnixMain + 111
    frame #18: 0x00007fff5f6e63d5 libdyld.dylib`start + 1

Información de la versión de Numpy / Python:

He reproducido esto en Mac OS X con:

1.17.0 3.7.2 (default, Jan 16 2019, 11:36:28)
[Clang 10.0.0 (clang-1000.11.45.2)]

y en una compilación interna de Linux.

Este problema se informó originalmente como https://github.com/google/jax/issues/1162

00 - Bug

Fuente

hawkinsp

Todos 6 comentarios

Hmm, vdot comprueba cuál será el tipo de salida antes de tiempo (lo que supongo que está bien). Sin embargo, esa función puede fallar y devolver NPY_NOTYPE , por lo que debería devolver un error cuando se devuelva NPY_NOTYPE . Esto está en https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/multiarraymodule.c#L2241 (y la siguiente línea), el error que ves es un error que regresa más adelante, pero creo que esa función realmente no debería devolver un error (aunque estaría bien agregar una verificación de error allí también).

¿Quieres hacer relaciones públicas?

(Sería bueno comprobar si hay usos más similares en los que falta la comprobación de errores).

seberg en 10 ago. 2019

Hola,
Soy un recién llegado y me gustaría trabajar en este tema. ¿Alguna pista sobre por dónde empezar?
Gracias por adelantado.

Soniyanayak51 en 20 ago. 2019

Lea sobre nuestro flujo de trabajo de desarrollo . Entonces deberías llegar a un punto en el que puedas ejecutar python runtests.py de la rama master ( git checkout master; git clean -xfd; python runtests.py ).

Cuando esté configurado, puede comenzar a piratear: cree una rama, agregue una prueba fallida ( numpy/core/tests/teste_multiarray.py en TestVDot sería un buen lugar), intente corregir el código C de la sugerencia anterior . Si se queda atascado, no dude en pedir ayuda, cuanto más pueda demostrar que hizo un verdadero esfuerzo para seguir la documentación y las sugerencias, mejor.

mattip en 20 ago. 2019

👍1

¡Bienvenido @ Soniyanayak51!

Para agregar a lo que dijo @mattip : un poco de información que falta en nuestros documentos (creo) es cómo trabajamos en los problemas. No usamos la función de "asignados" de GitHub, por lo que, a menos que esté claro por los comentarios / relaciones públicas recientes que alguien está trabajando activamente en un problema, puede sumergirse.

rgommers en 20 ago. 2019

👍1

@rgommers @mattip He agregado comprobaciones para los tipos obtenidos de PyArray_DescrFromType (). No estoy seguro de si debería agregarlos también para PyArray_DESCR ().
Además, sobre cómo agregar pruebas en test_multiarray.py, ¿debo agregar un test_PyArrayType y agregar pruebas donde el tipo es NULL? No estoy seguro de cómo avanzar con la adición de pruebas.

Soniyanayak51 en 21 ago. 2019

@rgommers @mattip He agregado comprobaciones para los tipos obtenidos de PyArray_DescrFromType (). No estoy seguro de si debería agregarlos también para PyArray_DESCR ().
Además, sobre cómo agregar pruebas en test_multiarray.py, ¿debo agregar un test_PyArrayType y agregar pruebas donde el tipo es NULL? No estoy seguro de cómo avanzar con la adición de pruebas.

Parece que @mattip respondió esto en parte en las relaciones públicas (creo). Probablemente sea mejor mantener la conversación ahí.