-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
julia core constructor destructor #53
Comments
Anhand der Strack-Traces unten kann man sehen, dass HDF5 versucht, alle JULEA-Bibliotheken nacheinander zu laden (und sie dann wieder entlädt, da sie keine HDF5-Plugins sind). Dabei werden jedes Mal Welches Problem tritt denn genau mit |
Ich habe mir jetzt ein minimal working hdf5 example geschrieben. (H5VLinitialize und H5VLterminate sind überflüssig - und sollten auch aus julea-test gelöscht werden):
gcc example.c -lhdf5 -ggdb "und sie dann wieder entlädt, da sie keine HDF5-Plugins sind" für die gegeben logs hast du recht. Ich habe das heute nochmal ausgeführt, dieses Mal mit: export LD_LIBRARY_PATH="/src/julea/prefix-hdf-julea/lib:$LD_LIBRARY_PATH" Wobei in dem Pfad "/src/julea/prefix-hdf-julea/lib/plugin" nur genau die eine hdf5-plugin-lib war. component=server funktioniert also - nach deiner Erklärung - wie erwartet. Bei component=client passt deine Erklärung allerdings nicht. export LD_LIBRARY_PATH="/src/julea/prefix-hdf-julea/lib:$LD_LIBRARY_PATH" Funktioniert alles super wie erwartet - genau wie bei component=server, ABER export LD_LIBRARY_PATH="/src/julea/prefix-hdf-julea/lib:$LD_LIBRARY_PATH" Also bei allen libs im gleichen Ordner, ist das anders. Das erste j_init ist ok, aber das zweite (verschachtelte) nicht.
|
Ich vermute, das Problem kommt daher: HDF5 lädt Ich sehe momentan zwei Möglichkeiten, das zu reparieren:
|
Der Konstruktor wird zweimal aufgerufen, weil zwei unterschiedliche Versionen von Ich überlege mir mal, wie man das sauberer lösen kann. |
Variante 1 halte ich für schöner. |
Für den Anfang wäre es schon extrem hilfreich, wenn jede einzelne libjulea*.so beim geladen werden "g_debug(..git-hash..voller-ordner-pfad-mit-lib-namen..compile-flags..)" ausgeben würde. Langfristig wäre es sinnvoll, wenn "waf.sh configure prefix= ..." nicht nur den Ordner ändert, wo die lib landet, sondern auch "sicherstellt", dass alle libs aus dem gleichen Ordner geladen werden. |
This should fix issues with installed debug builds loading backends from the build directory. Debug builds still allow overriding the backend directory with the JULEA_BACKEND_PATH environment variable, though.
Das Prefix legt bereits fest, von wo die Backends geladen werden. Bisher haben Debug-Builds allerdings immer zuerst Backends aus dem Build-Verzeichnis geladen. Mit Commit 5e45247 habe ich das geändert, so dass Backends aus dem Prefix bevorzugt werden. Das sollte solche Probleme hoffentlich zumindest unwahrscheinlicher machen. |
Man kann aus der Bibliothek heraus wohl nicht herausfinden, aus welchem Pfad sie geladen wurde, daher wird das vermutlich nicht so einfach machbar sein. |
Bei mir waren die Probleme bisher beim release build, und nicht beim debug-build. |
g_debug(..git-hash..compile-flags..) kann man leicht herausfinden und z.b. erst in die julea-config.h schreiben, und beim initialisieren einmal Ausgeben. Das würde zumindest verhindern, dass ich immer wieder irgendwelche uralt-libs mit dazwischen lade. |
Das muss dann daran gelegen haben, dass du alte Versionen im Prefix oder LD_LIBRARY_PATH liegen hattest. JULEA selbst lädt die Backends aus dem Prefix. Da die Backends allerdings nochmal gegen
Dann kann aber immer noch zweimal die gleiche Version (einmal aus dem Prefix, einmal aus dem Build-Verzeichnis) geladen werden. Optimal wäre vermutlich, wenn wir irgendwie herausfinden könnten, ob Edit: Zur Laufzeit lässt sich mit |
Gibt es hier noch etwas zu tun? Falls nicht, würde ich das Issue schließen. |
Aktuell funktioniert bei mir alles, allerdings bin ich auch gerade nicht dabei neue skripte zu schreiben |
Irgendwas mit dem julea constructor/destructor code ist merkwürdig.
Für die folgenden logs/stack-traces wurde in der julea-config wurde überall component=server angegeben.
Bei component=client crasht das Programm während des initialisierens - durch eine andere Reihenfolge von j_init / j_fini.
Zunächst 'nur' die gekürzten log Ausgaben:
"j_init 1" wird beim Betreten der j_init Funktion geloggt.
"j_init 2" NACHDEM j_is_initialized() überprüft wurde -> j_init erkennt also nie, dass bereits init ausgeführt worden ist.
"j_fini" wird beim Betreten der j_fini Funktion geloggt.
"H5PLget_plugin_type" und "H5PLget_plugin_info" werden jeweils in der julea-hdf5-implementation geloggt.
** (process:1384): DEBUG: 13:19:57.819: j_init 1
** (process:1384): DEBUG: 13:19:57.820: j_init 2
** (process:1384): DEBUG: 13:20:05.011: j_fini
** (process:1384): DEBUG: 13:20:07.689: j_init 1
** (process:1384): DEBUG: 13:20:07.689: j_init 2
** (process:1384): DEBUG: 13:20:09.971: j_fini
** (process:1384): DEBUG: 13:20:12.928: j_init 1
** (process:1384): DEBUG: 13:20:12.929: j_init 2
** (process:1384): DEBUG: 13:20:15.651: j_fini
** (process:1384): DEBUG: 13:20:17.261: j_init 1
** (process:1384): DEBUG: 13:20:17.261: j_init 2
** (process:1384): DEBUG: 13:20:17.262: H5PLget_plugin_type
** (process:1384): DEBUG: 13:20:17.262: H5PLget_plugin_info
Anschließend auch ein paar Stacktraces mit den obigen log Ausgaben dazwischen, um die zeitlichen Zusammenhänge zu sehen. Hierbei ist zu beachten, dass alle stacktraces innerhalb der selben "H5VLregister_connector_by_name" ausgegeben wurden.
Es werden mehrfach Threads initialisiert - und auch wieder beendet.
The text was updated successfully, but these errors were encountered: