opmd matplotlib.pylab crash (depending on import order)

[pgrete]

Describe the bug
Code crashes on import when openpmd is imported before matplotlib

To Reproduce
Compile-able/executable code example to reproduce the problem:

(py-oct25) pgrete@login10 ~ $ python -c "import openpmd_api as opmd; import matplotlib.pylab as plt; print('nope')"
Segmentation fault (core dumped)
(py-oct25) pgrete@login10 ~ $ python -c "import matplotlib.pylab as plt; import openpmd_api as opmd; print('yay')"
yay
(py-oct25) pgrete@login10 ~ $ python -c "import matplotlib as mpl; import openpmd_api as opmd; import matplotlib.pylab as plt; print('yay')"
yay

Expected behavior
No crash

Software Environment

• version of openPMD-api: current dev
• installed openPMD-api via: from source
• machine: Frontier
• name and version of Python implementation: CPython 3.11

[franzpoeschel]

I remember having had a very similar issue a while ago with Lammps and openPMD-api (mala-project/mala#476 (comment)). The same error pattern: Depending on import order, either a segfault or not.
In the related issue, the reason for the error was mainly a packaging error: Both packages were compiled against incompatible implementations of the C++ stdlib. Since the ABI of the stdlib is in parts identical, the loader jumped from lib A to lib B, or from B to A, depending which it saw first (hence the error only if you import things in a certain order).

The shortterm solution is probably to ensure a consistent build environment for both packages.
@ax3l We should maybe think of a way to not reexpose stdlib symbols?

[pgrete]

I see. Thanks for the quick pointer.

This helped me to work around the problem. I didn't use the python binding from my openpmd install (from source), but now installed the openpmd version from pip.

But practically, how would I fix this if I depend on features only enable/disabled in source builds (assuming I don't want to build an entire python/matplotlib/... stack from source)?

[franzpoeschel]

But practically, how would I fix this if I depend on features only enable/disabled in source builds (assuming I don't want to build an entire python/matplotlib/... stack from source)?

Since it seems to be openPMD injecting itself into Matplotlib in this case, probably not very easily..
(If things were reversed, i.e. a crash in openPMD that jumps into Matplotlib, recompiling with -fvisibility=protected may be an option since that prevents symbols from being resolved externally, as far as I understand it).
As things are, I only see the solution of compiling openPMD with -fvisibility=hidden so that Matplotlib does not even get to see our internal symbols, but that means we will need to manually export those of our symbols that should remain default-visible. TLDR: Can be done, but requires some work on our side.
I'll need to discuss with Axel what solution would be best.

[pgrete]

Potentially related question: does the pypi version of openpmd come with an internal version of adios2?
I just tried to load compressed data (in python) and got

ValueError: [Tue Oct 14 08:23:32 2025] [ADIOS2 EXCEPTION] <Operator> <OperatorFactory> <MakeOperator> : ADIOS2 didn't compile with sz library, operator not added

on series.flush().
However, the environment I'm running in uses an adios2 version with sz support (adios2/2.10.2-mpi on Frontier) which I used minutes before to generate the data.

[franzpoeschel]

Potentially related question: does the pypi version of openpmd come with an internal version of adios2?

Yes, it comes with a static build of ADIOS2 included.
Heavily WIP, but #1793 is an attempt at fixing the original issue. But you're currently likely to get undefined-symbol errors when using that branch. Current state works with some versions of Clang and g++.

[ax3l]

Potentially related question: does the pypi version of openpmd come with an internal version of adios2?

Correct, we compile and self-contain the PyPI wheels. SZ is missing, we can add it here to the library_builders.*: https://github.com/openPMD/openPMD-api/tree/wheels

[ax3l]

Thank you for the report!

I am surprised this is an issue, because we do hide the symbols of the Python library we expose:

openPMD-api/CMakeLists.txt

Lines 612 to 613 in 21adf5a

	set_target_properties(openPMD.py PROPERTIES CXX_VISIBILITY_PRESET "hidden"
	CUDA_VISIBILITY_PRESET "hidden")

Is there anything special with your from-source build, e.g., did you build in Debug (which disables symbol hiding)?

[ax3l]

To debug this further, can you please run gdb on the segfaulting logic?

gdb --ex r --ex bt python -c "import openpmd_api as opmd; import matplotlib.pylab as plt; print('nope')"

How did you install matplotlib?
Are both installed against the same Python module on Frontier?

[ax3l]

My guess is that the build on Frontier mixes stdlibs/compilers from where Python, matplotlib and openPMD-api are based on. (I do not think that #1793 will help here, unfortunately.)

This can be controlled via environment variables, e.g., loading a consistent set of modules and setting CC/CXX. Here is an example how to build a consistent C++ HIP stack with Python on Frontier (see profile file and dependencies install script): https://warpx.readthedocs.io/en/latest/install/hpc/frontier.html

If you like to debug (and post here) the dynamic libraries loaded by matplotlib and openPMD-api, try https://github.com/haampie/libtree on the dynamic libraries / compiled module files -- it's like ldd but recursive and more informative.