Shapeworks: Crash avec "femur --groom_images" sur MacOS

Est-ce qu'il plante avec tiny_test ?

Le tiny_test ne plante pas.

Cela pourrait avoir quelque chose à voir avec les fémurs réfléchis alors parce que le petit test n'a laissé que des fémurs.

Mise à jour : j'ai vérifié et cela semble fonctionner sous Linux.

J'ai essayé d'exécuter tiny_test avec 2 fémurs gauches et un fémur droit. Aucun problème là-bas.

* 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

Cela pourrait-il être lié au #1168 ?

Pourquoi ITKIOImageBasePython.so apparaît-il dans cette trace de pile ? Je pensais que nous utilisions des liaisons python shapeworks (par exemple, la classe Image)?

De plus, certains avertissements lldb sont émis juste avant qu'il ne se bloque :

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.

Cela se produit-il également lors de l'étape de centrage dans le cas d'utilisation de l'oreillette gauche ?

Est-ce qu'il se bloque également lors du débogage ? Il pourrait divulguer une trace de pile plus complète. Depuis
L'image est construite autour d'itk::Image certains appels aux fonctions d'image de ShapeWorks
pourrait simplement être optimisé.

Il y a longtemps et très loin (la branche n'existe peut-être plus) j'ai essayé de construire
les liaisons Python d'itk avec itk dans build_dependencies, mais je n'étais pas
à succès. Je soupçonne que cela vaut la peine d'essayer, d'autant plus que conda/pip est
notamment installer différentes versions de certains, mais pas tous, itk python
composants (5.0 et 5.1), une recette flagrante pour les ennuis.

Le jeu. 25 mars 2021 à 11:59 Alan Morris @ . * >
a écrit:

• thread #1, file d'attente = 'com.apple.main-thread', raison d'arrêt = EXC_BAD_ACCESS (code=1, address=0x0)
  
  
  
  • cadre #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=, solde=) à vnl_determinant. hxx:107 :14 [option]
    
    cadre #2 : 0x00000003dec807ac _ITKIOImageBasePython.so ___lldb_unnamed_symbol9961$$_ITKIOImageBasePython.so + 252 frame #3: 0x00000003deba7ff4 _ITKIOImageBasePython.so ___lldb_unnamed_symbol7056$$_ITKIOImageBasePython.so + 132
    
    cadre n°4 : 0x00000003dec80586 _ITKIOImageBasePython.so ___lldb_unnamed_symbol9956$$_ITKIOImageBasePython.so + 38 frame #5: 0x00000003dea1d188 _ITKIOImageBasePython.so ___lldb_unnamed_symbol1480$$_ITKIOImageBasePython.so + 1560
    
    cadre #6 : 0x00000003ded50753 _ITKIOImageBasePython.so itk::ProcessObject::UpdateOutputInformation() + 351 frame #7: 0x00000003dec7fec2 _ITKIOImageBasePython.so ___lldb_unnamed_symbol9945$$_ITKIOImageBasePython.so + 70
    
    cadre #8 : 0x00000003ded5b6f4 _ITKIOImageBasePython.so itk::DataObject::Update() + 18 frame #9: 0x000000041a65c177 _ITKCommonPython.so ___lldb_unnamed_symbol8759$$_ITKCommonPython.so + 58
    
    cadre #10 : 0x000000010002c843 python _PyMethodDef_RawFastCallKeywords + 131 frame #11: 0x000000010002c1d6 python _PyObject_FastCallKeywords + 598
    
    cadre #12 : 0x0000000100164bb7 python call_function + 455 frame #13: 0x000000010015c604 python _PyEval_EvalFrameDefault + 20180
    
    cadre #14 : 0x0000000100155f04 python _PyEval_EvalCodeWithName + 532 frame #15: 0x000000010002c5e3 python _PyFunction_FastCallKeywords + 403
    
    cadre #16 : 0x0000000100164aa7 python call_function + 183 frame #17: 0x000000010015c604 python _PyEval_EvalFrameDefault + 20180
    
    frame #18 : 0x0000000010002c535 python _PyFunction_FastCallKeywords + 229 frame #19: 0x0000000100164aa7 python call_function + 183
    
    cadre #20 : 0x000000010015cdb0 python _PyEval_EvalFrameDefault + 22144 frame #21: 0x0000000100155f04 python _PyEval_EvalCodeWithName + 532
    
    cadre #22 : 0x0000000010002c5e3 python _PyFunction_FastCallKeywords + 403 frame #23: 0x0000000100164aa7 python call_function + 183
    
    cadre #24 : 0x000000010015c604 python _PyEval_EvalFrameDefault + 20180 frame #25: 0x0000000100155f04 python _PyEval_EvalCodeWithName + 532
    
    cadre #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
    
    cadre #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
    
    cadre #34 : 0x00007fff6aedfcc9 libdyld.dylib`start + 1
  
  

Cela pourrait-il être lié à #1168
https://github.com/SCIInstitute/ShapeWorks/issues/1168

-
Vous recevez ceci parce que vous avez été affecté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/SCIInstitute/ShapeWorks/issues/1179#issuecomment-807193351 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAJT3EKCRFSERHDJ5XDPHCDTFN2ZPANCNFSM4ZZUXDBQ
.

Mettre à jour. Ok, j'étais confus par la sortie Python, j'ai supposé qu'elle était toujours au centre car il n'y avait plus de sortie. Il plante dans FindReferenceImage :

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

Je suppose que le problème est que nous avons deux bibliothèques ITK différentes chargées en mémoire. ??

Il y a longtemps et très loin (la branche n'existe peut-être plus), j'ai essayé de créer les liaisons Python d'itk avec itk dans build_dependencies, mais je n'ai pas réussi. Je soupçonne que cela vaut la peine d'essayer, d'autant plus que conda/pip installe notamment différentes versions de certains, mais pas de tous, les composants python d'itk (5.0 et 5.1), une recette flagrante pour les ennuis.

Je suis d'accord que cela pourrait résoudre ce problème, mais qu'en est-il du #1168. Avons-nous alors besoin de créer des itkwidgets à partir de zéro et de les fournir également pour qu'ils soient construits avec notre ITK ?

Je suis d'accord que cela pourrait résoudre ce problème, mais qu'en est-il du #1168. Avons-nous alors besoin de créer des itkwidgets à partir de zéro et de les fournir également pour qu'ils soient construits avec notre ITK ?

S'il s'agit d'un problème de bibliothèque partagée, nous pouvons peut-être définir LD_LIBRARY_PATH avant d'exécuter le notebook.
mise à jour : j'ai essayé ceci et le résultat était le même
update2 : j'ai seulement essayé le cas d'utilisation #1168, pas celui-ci.

Il plante dans FindReferenceImage :

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

ShapeWorks n'est pas impliqué dans cet appel. Je me demande si plus d'informations pourraient être nettoyées en exécutant ceci via pdb :
python -m pub RunUseCase.py --use_case femur --groom_images (puis appuyez sur 'r' pour exécuter)

(Je l'exécute maintenant. Combien de temps faut-il pour planter ? Quelqu'un a-t-il pu réduire cela ?)
mise à jour : cela prend autant de temps (environ une heure), mais ce qui est moins utile, c'est qu'il ne signale qu'une erreur de segmentation et ne vous laisse même pas dans le débogueur. Je ne vois pas d'appel à un script externe, donc je suis confus par cela.

Le problème semble être que la bibliothèque python ITK résout et appelle notre bibliothèque VXL plutôt que celle avec laquelle elle a été construite :

  * 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

Rappelez-vous que nous construisons notre ITK avec un VXL/VNL alternatif, pas celui de l'ITK. libvnl_algo.dylib est à nous, _ITKIOImageBasePython.so vient de conda.

Nous mélangeons différentes versions, il n'est donc pas surprenant que ça plante.

@archanasri et moi avons juste essayé d'inverser l'ordre des
Je pense que la solution au problème #1168 est pour nous de simplement créer des itkwidgets (nous essayons cela maintenant).
Pour ce problème, pouvons-nous le pointer sur notre vnl comme nous le pointons sur notre eigen ?

Nous avons déjà ITK en utilisant notre VXL.

-DITK_USE_SYSTEM_VXL=on -DVXL_DIR=${INSTALL_DIR}

Mettre à jour. Ok, j'étais confus par la sortie Python, j'ai supposé qu'elle était toujours au centre car il n'y avait plus de sortie. Il plante dans FindReferenceImage :

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

Je suppose que le problème est que nous avons deux bibliothèques ITK différentes chargées en mémoire. ??

Au lieu d'utiliser python itk, nous pouvons utiliser shapeworks.Image.toArray(). J'ai donc remplacé

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

avec

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

Il ne plante pas maintenant.

Bien @archanasri. Ouais, j'ai pensé qu'on pourrait contourner ça de cette façon. Nous devons essentiellement nous assurer que nous n'utilisons pas python itk + notre itk en même temps. Je pense que le problème itkwidgets est le plus gros problème, car je suppose qu'il utilise l'interface python ITK en interne.

Oui, et nous ne sommes pas en mesure de créer des itkwidgets.
Nous devons trouver un moyen pour itkwidgets d'utiliser notre itk.

Oui, et nous ne sommes pas en mesure de créer des itkwidgets.
Nous devons trouver un moyen pour itkwidgets d'utiliser notre itk.

Dans itkwidgets 0.32.0 (dernière version balisée) setup.py, il spécifie ces exigences :

    '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',
    ],

Pour itk, je pense que cela nous ramène à la construction du python.
Une autre façon d'aborder cela serait de s'assurer qu'il s'agit des versions installées par pip (principalement) et conda.
Les versions de tous ces éléments sur mon système sont toutes plus récentes.

Voici ce que j'ai :

(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

Un drapeau rouge est les versions 5.0.1 d'itk-io, -registration, -segmentation, et surtout, itk lui-même.

J'ai mis à jour les installations pip au plus tard (il y avait une raison pour laquelle nous ne pouvions pas le faire, mais en mettant cela de côté pour le moment) et j'ai reconstruit toutes les dépendances. #1168 se bloque toujours de la même manière qui y est décrite.

Fixé.