You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There appears to be a fatal interaction between helics and the pyvalhalla packages on linux that causes the python process to crash if helics is imported before valhalla.
What is the expected behavior?
Both packages should import successfully regardless of the import order.
To Reproduce
$ pip install helics pyvalhalla
$ python
>>> import helics
>>> import valhalla
terminate called after throwing an instance of 'std::bad_cast'
what(): std::bad_cast
Aborted (core dumped)
Environment (please complete the following information):
Operating System: Linux (Linux xxxxx 4.18.0-513.11.1.el8_9.x86_64 #1 SMP Thu Dec 7 03:06:13 EST 2023 x86_64 x86_64 x86_64 GNU/Linux)
Language Extension: Python [python 3.11.0]
what compiler or setup process did you use: pip
HELICS version: 3.5.3
$ helics_app --version
3.5.3 (2024-07-08)
Additional context and information
This could possibly be a bug in either of the packages, but I'm reporting it here first because I recently also ran into a SEGFAULT that appeared to happen when helics was imported before matplotlib (I couldn't reliably reproduce this outside of github actions though). One of my colleagues apparently was able to reproduce it via
python -c "from helics import HelicsFederate; import matplotlib.pyplot as plt"
However, I have not been able to reproduce it using that method. Apparently just importing matplotlib before helics once, even in a separate python session, resolves the issue. For example, this will work:
python -c "import matplotlib.pyplot as plt"
python -c "from helics import HelicsFederate; import matplotlib.pyplot as plt"
If you think the problem is with pyvalhalla, I'm happy to report it over there. Pyvalhalla is also a thin python veneer around a C/C++ library, so it may just be some kind of interaction when the libraries are loaded into the interpreter and not even a bug per-se.
The text was updated successfully, but these errors were encountered:
We've seen the matplotlib issue before. I think it is some kind of interaction between the C++ standard library static linked to helics being newer (?) than the one used by matplotlib/pyvalhalla.
I don't think there's anything that can be done about it, since the alternative is imposing a requirement for users to install an ABI compatible version of the C++ standard library on their system -- which results in more headaches than re-ordering the Python imports.
Totally fair; I already re-ordered my imports by the time I submitted this. Hopefully the next person to run in to it will see this and not need to trace through all their imports to figure that out too!
Describe the bug
There appears to be a fatal interaction between helics and the pyvalhalla packages on linux that causes the python process to crash if helics is imported before valhalla.
What is the expected behavior?
Both packages should import successfully regardless of the import order.
To Reproduce
Environment (please complete the following information):
Linux xxxxx 4.18.0-513.11.1.el8_9.x86_64 #1 SMP Thu Dec 7 03:06:13 EST 2023 x86_64 x86_64 x86_64 GNU/Linux
)3.5.3 (2024-07-08)
Additional context and information
This could possibly be a bug in either of the packages, but I'm reporting it here first because I recently also ran into a SEGFAULT that appeared to happen when helics was imported before matplotlib (I couldn't reliably reproduce this outside of github actions though). One of my colleagues apparently was able to reproduce it via
However, I have not been able to reproduce it using that method. Apparently just importing matplotlib before helics once, even in a separate python session, resolves the issue. For example, this will work:
If you think the problem is with pyvalhalla, I'm happy to report it over there. Pyvalhalla is also a thin python veneer around a C/C++ library, so it may just be some kind of interaction when the libraries are loaded into the interpreter and not even a bug per-se.
The text was updated successfully, but these errors were encountered: