Shapeworks: Absturz mit "femur --groom_images" auf MacOS

Stürzt es mit tiny_test ab?

Der tiny_test stürzt nicht ab.

Könnte dann etwas mit den reflektierten Oberschenkelknochen zu tun haben, da der kleine Test nur linke Oberschenkelknochen hat.

Update: Ich habe es doppelt überprüft und es scheint unter Linux zu funktionieren.

Ich habe versucht, tiny_test mit 2 linken Oberschenkelknochen und einem rechten Oberschenkelknochen auszuführen. Da gibt es keine Probleme.

* 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

Könnte das mit #1168 zusammenhängen?

Warum wird ITKIOImageBasePython.so in diesem Stack-Trace angezeigt? Ich dachte, wir verwenden Shapeworks-Python-Bindungen (zB Image-Klasse)?

Außerdem spuckte lldb einige Warnungen aus, kurz bevor es abstürzte:

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.

Geschieht dies auch im Zentrierungsschritt im Anwendungsfall des linken Atriums?

Stürzt es auch beim Debuggen ab? Es könnte einen vollständigeren Stack-Trace preisgeben. Schon seit
Image basiert auf itk::Image einige Aufrufe von ShapeWorks Image-Funktionen
könnte einfach optimiert werden.

Vor langer Zeit und weit weg (die Filiale existiert vielleicht nicht mehr) habe ich versucht zu bauen
itk's Python-Bindungen zusammen mit itk in build_dependencies, aber ich war es nicht
erfolgreich. Ich vermute, es ist einen weiteren Versuch wert, zumal Conda / Pip ist
insbesondere die Installation verschiedener Versionen von einigen, aber nicht allen, itk python
Komponenten (5.0 und 5.1), ein krasses Rezept für Ärger.

Am Do, 25. März 2021 um 11:59 Alan Morris @ . * >
schrieb:

• Thread #1, Queue = 'com.apple.main-thread', Stoppgrund = EXC_BAD_ACCESS (Code=1, Adresse=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(M=, Gleichgewicht=) bei vnl_determinant. hxx:107 :14 [
    
    Bild #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: 0x0000001001c1afb python PyRun_FileExFlags + 235 frame #27: 0x00000001001c14c6 python PyRun_SimpleFileExFlags + 502
    
    Frame #28: 0x0000001001ede30 python pymain_run_file + 160 frame #29: 0x00000001001ed72b python pymain_run_filename + 123
    
    Frame #30: 0x0000001001ecf11 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
  
  

Könnte das mit #1168 zusammenhängen?
https://github.com/SCIInstitute/ShapeWorks/issues/1168

—
Sie erhalten dies, weil Sie zugewiesen wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/SCIInstitute/ShapeWorks/issues/1179#issuecomment-807193351 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAJT3EKCRFSERHDJ5XDPHCDTFN2ZPANCNFSM4ZZUXDBQ
.

Aktualisieren. Ok, ich war verwirrt von der Python-Ausgabe, ich ging davon aus, dass sie sich immer noch auf der mittleren Stufe befand, da keine weitere Ausgabe erfolgte. Es stürzt in FindReferenceImage ab:

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

Ich vermute, dass das Problem darin besteht, dass wir zwei verschiedene ITK-Bibliotheken im Speicher geladen haben. 👎

Vor langer Zeit und weit entfernt (der Zweig existiert möglicherweise nicht mehr) habe ich versucht, die Python-Bindungen von itk zusammen mit itk in build_dependencies zu bauen, aber ich war nicht erfolgreich. Ich vermute, es ist einen weiteren Versuch wert, zumal conda/pip insbesondere verschiedene Versionen einiger, aber nicht aller itk-Python-Komponenten (5.0 und 5.1) installiert, ein krasses Rezept für Ärger.

Ich stimme zu, dass dieses Problem möglicherweise behoben wird, aber was ist mit #1168. Müssen wir dann itkwidgets von Grund auf neu bauen und auch bereitstellen, damit es mit unserem ITK gebaut wird?

Ich stimme zu, dass dieses Problem möglicherweise behoben wird, aber was ist mit #1168. Müssen wir dann itkwidgets von Grund auf neu bauen und auch bereitstellen, damit es mit unserem ITK gebaut wird?

Wenn dies ein Problem mit der gemeinsam genutzten Bibliothek ist, können wir möglicherweise LD_LIBRARY_PATH festlegen, bevor das Notebook ausgeführt wird.
Update: Ich habe es versucht und das Ergebnis war das gleiche
update2: Ich habe nur den Anwendungsfall Nr. 1168 ausprobiert, nicht diesen.

Es stürzt in FindReferenceImage ab:

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

ShapeWorks ist an diesem Aufruf nicht beteiligt. Ich frage mich, ob weitere Informationen bereinigt werden könnten, indem Sie dies über pdb :
python -m pub RunUseCase.py --use_case femur --groom_images (dann 'r' drücken, um zu starten)

(Ich führe das jetzt aus. Wie lange dauert es, bis es abstürzt? Hat jemand dies reduzieren können?)
update: es dauert so lange (~eine Stunde), aber weniger hilfreich ist, dass es nur einen Seg-Fehler meldet und Sie nicht einmal im Debugger zurücklässt. Ich sehe keinen Aufruf an ein externes Skript, daher bin ich dadurch verwirrt.

Das Problem scheint zu sein, dass die Python-ITK-Bibliothek unsere VXL-Bibliothek auflöst und aufruft, anstatt die, mit der sie erstellt wurde:

  * 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

Denken Sie daran, dass wir unser ITK mit einem alternativen VXL/VNL aufbauen, nicht mit dem ITK. libvnl_algo.dylib gehört uns, _ITKIOImageBasePython.so ist von Conda.

Wir mischen verschiedene Versionen, daher ist es nicht verwunderlich, dass es abstürzt.

@archanasri und ich haben gerade versucht, die Reihenfolge der
Ich denke, die Lösung für das Problem Nr. 1168 besteht darin, dass wir einfach itkwidgets erstellen (das versuchen wir jetzt).
Können wir für dieses Problem itk auf unser vnl verweisen, wie wir es auf unser eigen ?

Wir haben bereits ITK mit unserem VXL.

-DITK_USE_SYSTEM_VXL=on -DVXL_DIR=${INSTALL_DIR}

Aktualisieren. Ok, ich war verwirrt von der Python-Ausgabe, ich ging davon aus, dass sie sich immer noch auf der mittleren Stufe befand, da keine weitere Ausgabe erfolgte. Es stürzt in FindReferenceImage ab:

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

Ich vermute, dass das Problem darin besteht, dass wir zwei verschiedene ITK-Bibliotheken im Speicher geladen haben. 👎

Anstatt Python itk zu verwenden, können wir shapeworks.Image.toArray() verwenden. Also habe ich ersetzt

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

mit

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

Es stürzt jetzt nicht ab.

Schön @archanasri. Ja, ich dachte, wir könnten es so umgehen. Wir müssen grundsätzlich sicherstellen, dass wir Python itk + unser itk nicht gleichzeitig verwenden. Ich denke, das itkwidgets-Problem ist jedoch das größere Problem, da ich davon ausgehe, dass es intern die ITK-Python-Schnittstelle verwendet.

Ja, und wir sind nicht in der Lage, itkwidgets zu bauen.
Wir müssen einen Weg für itkwidgets finden, unsere itk zu verwenden.

Ja, und wir sind nicht in der Lage, itkwidgets zu bauen.
Wir müssen einen Weg für itkwidgets finden, unsere itk zu verwenden.

In itkwidgets 0.32.0 (neueste getaggte Version) setup.py gibt es diese Anforderungen an:

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

Für itk denke ich, dass uns dies wieder beim Bauen des Pythons zurückbringt.
Eine andere Möglichkeit, dies zu erreichen, besteht darin, sicherzustellen, dass dies die Versionen sind, die von pip (meistens) und conda installiert werden.
Die Versionen all dieser auf meinem System sind alle neuer.

Hier ist was ich habe:

(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

Ein Warnsignal sind die 5.0.1-Versionen von itk-io, -registration, -segmentation und vor allem itk selbst.

Ich habe die Pip-Installationen auf den neuesten Stand gebracht (es gab einen Grund, warum wir dies nicht tun konnten, aber das vorerst beiseite legen) und alle Abhängigkeiten neu erstellt. #1168 stürzt immer noch auf die dort beschriebene Weise ab.

Fest.