Shapeworks: Crash con "femur --groom_images" en MacOS

¿Se bloquea con tiny_test?

Tiny_test no se bloquea.

Entonces, podría tener algo que ver con los fémures reflejados porque la pequeña prueba solo ha dejado fémures.

Actualización: lo verifiqué dos veces y parece funcionar en Linux.

Intenté ejecutar tiny_test con 2 fémures izquierdos y un fémur derecho. No hay problemas allí.

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000000016b8612ad libvnl_algo.dylib`vnl_qr<double>::vnl_qr(this=0x00007ffeefbfd568, M=0x00007ffeefbfd6f0) at vnl_qr.hxx:51:24 [opt]
    frame #1: 0x000000016b85cf1d libvnl_algo.dylib`double vnl_determinant<double>(M=<unavailable>, balance=<unavailable>) at vnl_determinant.hxx:107:14 [opt]
    frame #2: 0x00000003dec807ac _ITKIOImageBasePython.so`___lldb_unnamed_symbol9961$$_ITKIOImageBasePython.so + 252
    frame #3: 0x00000003deba7ff4 _ITKIOImageBasePython.so`___lldb_unnamed_symbol7056$$_ITKIOImageBasePython.so + 132
    frame #4: 0x00000003dec80586 _ITKIOImageBasePython.so`___lldb_unnamed_symbol9956$$_ITKIOImageBasePython.so + 38
    frame #5: 0x00000003dea1d188 _ITKIOImageBasePython.so`___lldb_unnamed_symbol1480$$_ITKIOImageBasePython.so + 1560
    frame #6: 0x00000003ded50753 _ITKIOImageBasePython.so`itk::ProcessObject::UpdateOutputInformation() + 351
    frame #7: 0x00000003dec7fec2 _ITKIOImageBasePython.so`___lldb_unnamed_symbol9945$$_ITKIOImageBasePython.so + 70
    frame #8: 0x00000003ded5b6f4 _ITKIOImageBasePython.so`itk::DataObject::Update() + 18
    frame #9: 0x000000041a65c177 _ITKCommonPython.so`___lldb_unnamed_symbol8759$$_ITKCommonPython.so + 58
    frame #10: 0x000000010002c843 python`_PyMethodDef_RawFastCallKeywords + 131
    frame #11: 0x000000010002c1d6 python`_PyObject_FastCallKeywords + 598
    frame #12: 0x0000000100164bb7 python`call_function + 455
    frame #13: 0x000000010015c604 python`_PyEval_EvalFrameDefault + 20180
    frame #14: 0x0000000100155f04 python`_PyEval_EvalCodeWithName + 532
    frame #15: 0x000000010002c5e3 python`_PyFunction_FastCallKeywords + 403
    frame #16: 0x0000000100164aa7 python`call_function + 183
    frame #17: 0x000000010015c604 python`_PyEval_EvalFrameDefault + 20180
    frame #18: 0x000000010002c535 python`_PyFunction_FastCallKeywords + 229
    frame #19: 0x0000000100164aa7 python`call_function + 183
    frame #20: 0x000000010015cdb0 python`_PyEval_EvalFrameDefault + 22144
    frame #21: 0x0000000100155f04 python`_PyEval_EvalCodeWithName + 532
    frame #22: 0x000000010002c5e3 python`_PyFunction_FastCallKeywords + 403
    frame #23: 0x0000000100164aa7 python`call_function + 183
    frame #24: 0x000000010015c604 python`_PyEval_EvalFrameDefault + 20180
    frame #25: 0x0000000100155f04 python`_PyEval_EvalCodeWithName + 532
    frame #26: 0x00000001001c1afb python`PyRun_FileExFlags + 235
    frame #27: 0x00000001001c14c6 python`PyRun_SimpleFileExFlags + 502
    frame #28: 0x00000001001ede30 python`pymain_run_file + 160
    frame #29: 0x00000001001ed72b python`pymain_run_filename + 123
    frame #30: 0x00000001001ecf11 python`pymain_run_python + 145
    frame #31: 0x00000001001ecb8b python`pymain_main + 27
    frame #32: 0x00000001000018c9 python`main + 89
    frame #33: 0x00007fff6aedfcc9 libdyld.dylib`start + 1
    frame #34: 0x00007fff6aedfcc9 libdyld.dylib`start + 1

¿Podría esto estar relacionado con el # 1168?

¿Por qué aparece ITKIOImageBasePython.so en este seguimiento de pila? Pensé que estábamos usando enlaces de python de shapeworks (por ejemplo, clase de imagen).

Además, algunas advertencias que lldb escupe justo antes de fallar:

2021-03-25 11:57:01.360622-0600 python[22532:5953417] dynamic_cast error 1: Both of the following type_info's should have public visibility. At least one of them is hidden. N3itk10DataObjectE, N3itk5ImageIfLj3EEE.
2021-03-25 11:57:01.360667-0600 python[22532:5953417] dynamic_cast error 2: One or more of the following type_info's has hidden visibility or is defined in more than one translation unit. They should all have public visibility. N3itk10DataObjectE, N3itk5ImageIfLj3EEE, N3itk9ImageBaseILj3EEE.
2021-03-25 11:57:01.905525-0600 python[22532:5953417] dynamic_cast error 1: Both of the following type_info's should have public visibility. At least one of them is hidden. N3itk10DataObjectE, N3itk5ImageIfLj3EEE.
2021-03-25 11:57:01.905556-0600 python[22532:5953417] dynamic_cast error 2: One or more of the following type_info's has hidden visibility or is defined in more than one translation unit. They should all have public visibility. N3itk10DataObjectE, N3itk5ImageIfLj3EEE, N3itk9ImageBaseILj3EEE.
2021-03-25 11:57:02.113545-0600 python[22532:5953417] dynamic_cast error 1: Both of the following type_info's should have public visibility. At least one of them is hidden. N3itk10DataObjectE, N3itk5ImageIfLj3EEE.
2021-03-25 11:57:02.113577-0600 python[22532:5953417] dynamic_cast error 2: One or more of the following type_info's has hidden visibility or is defined in more than one translation unit. They should all have public visibility. N3itk10DataObjectE, N3itk5ImageIfLj3EEE, N3itk9ImageBaseILj3EEE.
2021-03-25 11:57:02.646500-0600 python[22532:5953417] dynamic_cast error 1: Both of the following type_info's should have public visibility. At least one of them is hidden. N3itk10DataObjectE, N3itk5ImageIfLj3EEE.
2021-03-25 11:57:02.646531-0600 python[22532:5953417] dynamic_cast error 2: One or more of the following type_info's has hidden visibility or is defined in more than one translation unit. They should all have public visibility. N3itk10DataObjectE, N3itk5ImageIfLj3EEE, N3itk9ImageBaseILj3EEE.
2021-03-25 11:57:03.535838-0600 python[22532:5953417] dynamic_cast error 1: Both of the following type_info's should have public visibility. At least one of them is hidden. N3itk10DataObjectE, N3itk5ImageIfLj3EEE.
2021-03-25 11:57:03.535870-0600 python[22532:5953417] dynamic_cast error 2: One or more of the following type_info's has hidden visibility or is defined in more than one translation unit. They should all have public visibility. N3itk10DataObjectE, N3itk5ImageIfLj3EEE, N3itk9ImageBaseILj3EEE.
2021-03-25 11:57:05.224328-0600 python[22532:5953417] dynamic_cast error 1: Both of the following type_info's should have public visibility. At least one of them is hidden. N3itk10DataObjectE, N3itk5ImageIfLj3EEE.
2021-03-25 11:57:05.224362-0600 python[22532:5953417] dynamic_cast error 2: One or more of the following type_info's has hidden visibility or is defined in more than one translation unit. They should all have public visibility. N3itk10DataObjectE, N3itk5ImageIfLj3EEE, N3itk9ImageBaseILj3EEE.

¿Está sucediendo esto también en el paso de centrado en el caso de uso de la aurícula izquierda?

¿También falla en la depuración? Podría divulgar un seguimiento de pila más completo. Ya que
La imagen se basa en itk :: Image algunas llamadas a las funciones de imagen de ShapeWorks
simplemente podría optimizarse.

Hace mucho tiempo y muy lejos (es posible que la rama ya no exista) intenté construir
enlaces de Python de itk junto con itk en build_dependencies, pero no estaba
exitoso. Sospecho que vale la pena intentarlo de nuevo, especialmente porque conda / pip es
notablemente instalando diferentes versiones de algunas, pero no todas, itk python
componentes (5.0 y 5.1), una receta descarada para problemas.

El jueves 25 de marzo de 2021 a las 11:59 a. M. Alan Morris @ . * >
escribió:

• hilo # 1, cola = 'com.apple.main-thread', motivo de parada = EXC_BAD_ACCESS (código = 1, dirección = 0x0)
  
  
  
  • marco # 0: 0x000000016b8612ad libvnl_algo.dylib vnl_qr<double>::vnl_qr(this=0x00007ffeefbfd568, M=0x00007ffeefbfd6f0) at vnl_qr.hxx:51:24 [opt] frame #1: 0x000000016b85cf1d libvnl_algo.dylib double vnl_determinant(M =, saldo =) en vnl_determinant. hxx: 107 : 14 [opt]
    
    marco # 2: 0x00000003dec807ac _ITKIOImageBasePython.so ___lldb_unnamed_symbol9961$$_ITKIOImageBasePython.so + 252 frame #3: 0x00000003deba7ff4 _ITKIOImageBasePython.so ___ lldb_unnamed_symbol7056 $$ _ ITKIOImageBasePython.so + 132
    
    marco # 4: 0x00000003dec80586 _ITKIOImageBasePython.so ___lldb_unnamed_symbol9956$$_ITKIOImageBasePython.so + 38 frame #5: 0x00000003dea1d188 _ITKIOImageBasePython.so ___ lldb_unnamed_symbol1480 $$ _ ITKIOImageBasePython.so + 1560
    
    marco # 6: 0x00000003ded50753 _ITKIOImageBasePython.so itk::ProcessObject::UpdateOutputInformation() + 351 frame #7: 0x00000003dec7fec2 _ITKIOImageBasePython.so ___ lldb_unnamed_symbol9945 $$ _ ITKIOImageBasePython.so + 70
    
    marco # 8: 0x00000003ded5b6f4 _ITKIOImageBasePython.so itk::DataObject::Update() + 18 frame #9: 0x000000041a65c177 _ITKCommonPython.so ___ lldb_unnamed_symbol8759 $$ _ ITKCommonPython.so + 58
    
    marco # 10: 0x000000010002c843 python _PyMethodDef_RawFastCallKeywords + 131 frame #11: 0x000000010002c1d6 python _PyObject_FastCallKeywords + 598
    
    marco # 12: 0x0000000100164bb7 python call_function + 455 frame #13: 0x000000010015c604 python _PyEval_EvalFrameDefault + 20180
    
    marco # 14: 0x0000000100155f04 python _PyEval_EvalCodeWithName + 532 frame #15: 0x000000010002c5e3 python _PyFunction_FastCallKeywords + 403
    
    marco # 16: 0x0000000100164aa7 python call_function + 183 frame #17: 0x000000010015c604 python _PyEval_EvalFrameDefault + 20180
    
    marco # 18: 0x000000010002c535 python _PyFunction_FastCallKeywords + 229 frame #19: 0x0000000100164aa7 python función_llamada + 183
    
    marco # 20: 0x000000010015cdb0 python _PyEval_EvalFrameDefault + 22144 frame #21: 0x0000000100155f04 python _PyEval_EvalCodeWithName + 532
    
    marco # 22: 0x000000010002c5e3 python _PyFunction_FastCallKeywords + 403 frame #23: 0x0000000100164aa7 python función_llamada + 183
    
    marco # 24: 0x000000010015c604 python _PyEval_EvalFrameDefault + 20180 frame #25: 0x0000000100155f04 python _PyEval_EvalCodeWithName + 532
    
    marco # 26: 0x00000001001c1afb python PyRun_FileExFlags + 235 frame #27: 0x00000001001c14c6 python PyRun_SimpleFileExFlags + 502
    
    marco # 28: 0x00000001001ede30 python pymain_run_file + 160 frame #29: 0x00000001001ed72b python pymain_run_filename + 123
    
    marco # 30: 0x00000001001ecf11 python pymain_run_python + 145 frame #31: 0x00000001001ecb8b python pymain_main + 27
    
    marco # 32: 0x00000001000018c9 python main + 89 frame #33: 0x00007fff6aedfcc9 libdyld.dylib inicio + 1
    
    fotograma # 34: 0x00007fff6aedfcc9 libdyld.dylib`start + 1
  
  

¿Podría esto estar relacionado con el n. ° 1168?
https://github.com/SCIInstitute/ShapeWorks/issues/1168

-
Está recibiendo esto porque fue asignado.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/SCIInstitute/ShapeWorks/issues/1179#issuecomment-807193351 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAJT3EKCRFSERHDJ5XDPHCDTFN2ZPANCNFSM4ZZUXDBQ
.

Actualizar. Ok, estaba confundido por la salida de Python, asumí que todavía estaba en el paso central ya que no había más salida. Se bloquea en FindReferenceImage:

    dim = itk.GetArrayFromImage(itk.imread(inDataList[i])).shape

Supongo que el problema es que tenemos dos bibliotecas ITK diferentes cargadas en la memoria. 👎

Hace mucho tiempo y muy lejos (es posible que la rama ya no exista) intenté construir los enlaces de Python de itk junto con itk en build_dependencies, pero no tuve éxito. Sospecho que vale la pena intentarlo de nuevo, especialmente porque conda / pip está instalando notablemente diferentes versiones de algunos, pero no todos, componentes de itk python (5.0 y 5.1), una receta flagrante para problemas.

Estoy de acuerdo en que podría solucionar este problema, pero ¿qué pasa con el # 1168? ¿Necesitamos entonces construir itkwidgets desde cero y proporcionar eso también para que esté construido con nuestro ITK?

Estoy de acuerdo en que podría solucionar este problema, pero ¿qué pasa con el # 1168? ¿Necesitamos entonces construir itkwidgets desde cero y proporcionar eso también para que esté construido con nuestro ITK?

Si se trata de un problema de biblioteca compartida, tal vez podamos configurar LD_LIBRARY_PATH antes de ejecutar el portátil.
actualización: probé esto y el resultado fue el mismo
update2: Solo probé el caso de uso # 1168, no este.

Se bloquea en FindReferenceImage:

    dim = itk.GetArrayFromImage(itk.imread(inDataList[i])).shape

ShapeWorks no participa en esta llamada. Me pregunto si se podría limpiar más información ejecutando esto a través de pdb :
python -m pub RunUseCase.py --use_case femur --groom_images (luego presione 'r' para ejecutar)

(Estoy ejecutando esto ahora. ¿Cuánto tiempo se tarda en bloquearse? ¿Alguien ha podido reducir esto?)
actualización: toma tanto tiempo (~ una hora), pero menos útil es que solo informa una falla seg y ni siquiera lo deja en el depurador. No veo una llamada a scripts externos, así que estoy confundido por eso.

El problema parece ser que la biblioteca Python ITK está resolviendo y llamando a nuestra biblioteca VXL en lugar de con la que fue construida:

  * frame #0: 0x000000016b8612ad libvnl_algo.dylib`vnl_qr<double>::vnl_qr(this=0x00007ffeefbfd568, M=0x00007ffeefbfd6f0) at vnl_qr.hxx:51:24 [opt]
    frame #1: 0x000000016b85cf1d libvnl_algo.dylib`double vnl_determinant<double>(M=<unavailable>, balance=<unavailable>) at vnl_determinant.hxx:107:14 [opt]
    frame #2: 0x00000003dec807ac _ITKIOImageBasePython.so`___lldb_unnamed_symbol9961$$_ITKIOImageBasePython.so + 252
    frame #3: 0x00000003deba7ff4 _ITKIOImageBasePython.so`___lldb_unnamed_symbol7056$$_ITKIOImageBasePython.so + 132

Recuerde que construimos nuestro ITK con un VXL / VNL alternativo, no el ITK. libvnl_algo.dylib es nuestro, _ITKIOImageBasePython.so es de conda.

Estamos mezclando diferentes versiones, por lo que no es sorprendente que se bloquee.

@archanasri y yo solo intentamos invertir el orden de las
Creo que la solución al problema # 1168 es simplemente construir itkwidgets (lo estamos intentando ahora).
Para este problema, ¿podemos señalarlo a nuestro vnl como lo hacemos con nuestro eigen ?

Ya tenemos ITK usando nuestro VXL.

-DITK_USE_SYSTEM_VXL=on -DVXL_DIR=${INSTALL_DIR}

Actualizar. Ok, estaba confundido por la salida de Python, asumí que todavía estaba en el paso central ya que no había más salida. Se bloquea en FindReferenceImage:

    dim = itk.GetArrayFromImage(itk.imread(inDataList[i])).shape

Supongo que el problema es que tenemos dos bibliotecas ITK diferentes cargadas en la memoria. 👎

En lugar de usar python itk, podemos usar shapeworks.Image.toArray (). Así que reemplacé

dim = itk.GetArrayFromImage(itk.imread(inDataList[i])).shape

con

img = Image(inDataList[i])
tmp = img.toArray()
dim = tmp.shape

No choca ahora.

Buen @archanasri. Sí, pensé que podríamos evitarlo de esa manera. Básicamente, debemos asegurarnos de no usar python itk + our itk al mismo tiempo. Creo que el problema de itkwidgets es el mayor problema, ya que supongo que usa la interfaz de Python de ITK internamente.

Sí, y no podemos construir itkwidgets.
Necesitamos encontrar una manera de que itkwidgets use nuestro itk.

Sí, y no podemos construir itkwidgets.
Necesitamos encontrar una manera de que itkwidgets use nuestro itk.

En itkwidgets 0.32.0 (última versión etiquetada) setup.py especifica estos requisitos:

    'install_requires': [
        'colorcet>=2.0.0',
        'itk-core>=5.1.0.post2',
        'itk-filtering>=5.1.0.post2',
        'itk-meshtopolydata>=0.6.2',
        'ipydatawidgets>=4.0.1',
        'ipywidgets>=7.5.1',
        'ipympl>=0.4.1',
        'matplotlib',
        'numpy',
        'six',
        'zstandard',
    ],

Por cierto, creo que esto nos vuelve a poner en la construcción de la pitón.
Otra forma de abordar esto sería asegurarse de que estas sean las versiones instaladas por pip (en su mayoría) y conda.
Las versiones de todos estos en mi sistema son todas más nuevas.

Esto es lo que tengo:

(shapeworks) cam<strong i="15">@ananda</strong>:~/code/ShapeWorks/ShapeWorks/Examples/Python$ conda list | grep itk
itk                       5.0.1                    pypi_0    pypi
itk-core                  5.1.2                    pypi_0    pypi
itk-filtering             5.1.2                    pypi_0    pypi
itk-io                    5.0.1                    pypi_0    pypi
itk-meshtopolydata        0.6.3                    pypi_0    pypi
itk-numerics              5.1.2                    pypi_0    pypi
itk-registration          5.0.1                    pypi_0    pypi
itk-segmentation          5.0.1                    pypi_0    pypi
itkwidgets                0.32.0                   pypi_0    pypi
(shapeworks) cam<strong i="16">@ananda</strong>:~/code/ShapeWorks/ShapeWorks/Examples/Python$ conda list | grep ipy
brotlipy                  0.7.0           py37hf967b71_1001    conda-forge
ipycanvas                 0.8.2                    pypi_0    pypi
ipydatawidgets            4.2.0                    pypi_0    pypi
ipyevents                 0.8.2                    pypi_0    pypi
ipykernel                 5.5.0            py37he01cfaa_1    conda-forge
ipympl                    0.7.0                    pypi_0    pypi
ipython                   7.21.0           py37he01cfaa_0    conda-forge
ipython_genutils          0.2.0                      py_1    conda-forge
ipyvtk-simple             0.1.4                    pypi_0    pypi
ipywidgets                7.6.3                    pypi_0    pypi

Una señal de alerta son las versiones 5.0.1 de itk-io, -registration, -segmentation y, sobre todo, itk en sí.

Actualicé las instalaciones de pip a la última (había alguna razón por la que no podíamos hacer esto, pero dejé eso de lado por ahora) y reconstruí todas las dependencias. # 1168 todavía se bloquea de las mismas formas descritas allí.

Reparado.