wake-up-neo.net

Schwerwiegender Fehler in der Erweiterung: PyThreadState_Get: Kein aktueller Thread

Ich habe mehrere Posts gesehen, die den gleichen Fehler angegeben haben, aber das Durchschauen und Ausprobieren der Antworten in diesen Posts hat nicht geholfen. Ich habe mich gefragt, ob jemand das ansehen und sehen kann, ob etwas herausspringt?

Ich baue eine Python-Erweiterung für eine CPP-Anwendung, und beim Kompilieren und Erstellen treten keine Fehler auf. Beim Import des Moduls erhalte ich jedoch den im Titel genannten Fehler. Andere stackoverflow-Antworten haben behauptet, dass dies darauf zurückzuführen ist, dass sie beim Kompilieren mit einer Bibliothek verbunden sind und einen anderen Interpreter verwenden. Soweit ich das beurteilen kann, verwende ich denselben Python-Interpreter. Ich werde jetzt beschreiben, warum ich denke, dass ich im Linking-Prozess und für den Interpreter denselben Python verwende.

Dies ist der Befehl, den ich zum Erstellen der Python-Erweiterung verwende

$ gcc -shared helicsPYTHON_wrap.c $(python-config3 --includes) -I/path/to/helics-0.9/includes -L/path/to/helics-0.9/lib -lhelicsSharedLib -L$(python3-config --prefix)/lib -lpython3.6m -o _helics.so

$ which python3-config
/Users/$USER/miniconda3/bin/python3-config

$ python3-config --prefix
/Users/$USER/miniconda3

Wenn ich versuche, die Python-Datei zu importieren, die die gemeinsam genutzte Bibliothek importiert, wird der schwerwiegende Fehler ausgelöst. Wenn ich otool -L in der gemeinsam genutzten Bibliothek verwende, erhalte ich Folgendes. Das ist was ich erwarte.

$ otool -L _helics.so
_helics.so:
        @rpath/libhelicsSharedLib.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libpython3.6m.dylib (compatibility version 3.6.0, current version 3.6.0)
        /usr/local/opt/zeromq/lib/libzmq.5.dylib (compatibility version 7.0.0, current version 7.3.0)
        libboost_program_options.dylib (compatibility version 0.0.0, current version 0.0.0)
        libboost_filesystem.dylib (compatibility version 0.0.0, current version 0.0.0)
        libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
        libboost_date_time.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/local/opt/gcc/lib/gcc/7/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.24.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
        /usr/local/lib/gcc/7/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

Ich habe auch versucht, install_name_tool den vollständigen Pfad der libpython3.6m.dylib hinzuzufügen.

$ install_name_tool -change @rpath/libpython3.6m.dylib /Users/$USER/miniconda3/envs/py3/lib/libpython3.6m.dylib _helics.so

Ich bekomme immer noch den gleichen fatalen Fehler. Meine Hypothese ist, dass meine Installation von Mac System Python 2.7 sich irgendwann auf diesen Prozess auswirkt. Ich kann aber nicht erkennen wo.

Gibt es eine Möglichkeit, weitere Debug-Anweisungen hinzuzufügen, um herauszufinden, warum es einen fatalen Python-Fehler gibt. Derzeit ist die Fehlermeldung sehr kurz.

$ python helics.py
Fatal Python error: PyThreadState_Get: no current thread

[1]    64481 abort      python helics.py

Wenn ich eine Conda-Umgebung und Python 2.7 verwende, kann ich die Erweiterung gut laden! Deshalb denke ich, dass ich, wenn ich Python 3.6 verwende, irgendwie etwas von der Standardinstallation von Mac System Python 2.7 aufgreift und gut funktioniert. Das gleiche gilt für mich, wenn ich die Conda 2.7-Python-Umgebung verwende. Da beide jedoch Python 2.7 sind (obwohl Conda 2.7.14 und System-Python 2.7.10 ist), scheint es zu funktionieren. Dies ist die otool -L-Ausgabe, wenn ich eine Conda-Umgebung verwende. 

$ otool -L _helics.so
_helics.so:
        @rpath/libhelicsSharedLib.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libpython2.7.dylib (compatibility version 2.7.0, current version 2.7.0)
        /usr/local/opt/zeromq/lib/libzmq.5.dylib (compatibility version 7.0.0, current version 7.3.0)
        libboost_program_options.dylib (compatibility version 0.0.0, current version 0.0.0)
        libboost_filesystem.dylib (compatibility version 0.0.0, current version 0.0.0)
        libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
        libboost_date_time.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/local/opt/gcc/lib/gcc/7/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.24.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
        /usr/local/lib/gcc/7/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

Ich habe folgende Fragen: 1) Wie bekomme ich aus dem Fehler von Python mehr Debug-Informationen? Ich habe python -vvv ausprobiert und das gibt mir nicht genug Informationen. Ich habe versucht, gdb zu verwenden, aber das gab mir auch keine Informationen. Ich glaube, dass es notwendig ist, Python selbst mit Debug-Symbolen neu zu kompilieren. 2) Haben Sie Empfehlungen, wie Sie dieses Problem lösen oder weiter debuggen können? 

Ich bin auch nicht sicher, ob dies nützliche Informationen sind, aber ich kann ctypes verwenden und die gemeinsam genutzte Bibliothek laden, nachdem ich sie erstellt habe. Ich kann es einfach nicht als Python-Modul importieren.

Dies ist die ursprüngliche Ausgabe, wenn man interessiert ist - https://github.com/GMLC-TDC/HELICS-src/issues/59

Edit: Ich habe das mit zsh und bash ausprobiert und habe trotzdem den gleichen Fehler erhalten. Ich habe auch versucht, den folgenden export PATH="/Users/$USER/miniconda3/bin:/Users/$USER/miniconda3/lib" vorübergehend in der Shell einzustellen und auszuführen, und ich bekomme immer noch die gleiche Fehlermeldung. Dies hätte mein Mac System Python 2.7.10 hätte ausschließen sollen, so dass ich wirklich nicht sicher bin, was los ist.

Nochmal editieren: Ich habe auch versucht, Miniconda mit Python2 neu zu installieren. Und wenn ich Python2 benutze, funktioniert alles gut. Ich kann Python3 einfach nicht mit Miniconda verwenden. Seltsamerweise, wenn ich Homebrew verwende und Python3 installiere, scheint das gut zu funktionieren.

Nochmal bearbeiten: Dies ist möglicherweise ein Problem mit High Sierra. Ich habe derzeit keinen Zugriff auf einen anderen Mac, aber ich habe das neueste Betriebssystem, das SIP hat. Ich bin nicht sicher, ob dies zu diesem Problem führt. Außerdem habe ich Anaconda3 ausprobiert und hatte kein Glück.

Erneut bearbeiten: Dies scheint sich nicht auf das Betriebssystem zu beziehen. Ich kann dies auf einem anderen Computer mit High Sierra erfolgreich ausführen. 

Nochmals editieren: Ich habe dies auf anderen neuen Betriebssysteminstallationen getestet und sie funktionieren nicht. Aber sie arbeiten auf zwei meiner Maschinen. Gibt es andere Tools, die Ihnen sagen, welche Abhängigkeit eine Bibliothek erfordert oder wo Python einen schwerwiegenden Fehler auslöst? Meine beste Vermutung im Moment ist, dass ich auf meinen anderen Maschinen in der Vergangenheit etwas installiert habe, das dies ermöglicht. Ich muss herausfinden, was das war und sicherstellen, dass ich es dokumentieren kann.

Nochmals editieren: Ich habe ein Gist der Ausgabe der Version von Python hinzugefügt, die ich verwende. 

Nochmal bearbeiten: Ich habe die Tags für Miniconda und Anaconda hinzugefügt, da dieses Problem bei der Verwendung von Homebrew Python3 nicht auftritt, aber nur, wenn ich Miniconda3 oder Anaconda2 in einer Python3-Umgebung verwende. Dies scheint immer mit Python2 zu funktionieren, unabhängig davon, ob es sich um Homebrew, Anaconda oder Miniconda handelt.

Nochmal bearbeiten:

Dies sind die Schritte, wenn eine andere Person auf ihrem Computer replizieren möchte.

git clone https://github.com/GMLC-TDC/HELICS-src
mkdir build-osx
brew install boost
brew install cmake
brew install swig
cmake -DBUILD_PYTHON=ON -DPYTHON_LIBRARY=$(python3-config --prefix)/lib/libpython3.6m.dylib -DPYTHON_INCLUDE_DIR=$(python3-config --prefix)/include/python3.6m/ ..
make
cd ./swig/python/
python helics.py # Error
15
kdheepak

Ich konnte dieses Problem lösen, indem ich CMakeLists.txt änderte, um -undefined dynamic_lookup wie in diese Antwort vorgeschlagen - zu verwenden. Z.B. der CMakeLists.txt ist hier . Und der Grund, warum ich auf verschiedenen Rechnern unterschiedliche Ergebnisse erhielt, war, dass einer meiner Macs Python 3.6.1 hatte, die anderen jedoch Python> = 3.6.2

2
kdheepak

Sie haben Python 3.6, von Homebrew ..., während Ihr Modul beim Erstellen von referenziertem Python 2.7 vom System bereitgestellt wird. Hier ist dasselbe Problem beschrieben. Aus einem der Kommentare - python3.6-config --ldflags wird LDFLAGS angezeigt, die in Ihrem Makefile verwendet werden soll. 

2

Vergewissern Sie sich, dass sich das lib-Verzeichnis des aktiven Python-Frameworks im Linker-Suchpfad befindet.

0
Abhi4967