Hi,
While creating and testing the GitHub Actions workflow for GSTools benchmarking , I noticed that the Rust backend through gstools_core segfaults with Python 3.14. The same minimal variogram smoke test works with any other version of python from 3.11 to 3.13 Python.
I am not sure yet whether this is caused by Python 3.14 compatibility, the gstools_core wheel/build, or something else. Below I show how to reproduce the error I've got.
Python 3.13 Control
Create an environment:
conda create -n gstools-rust-repro-py313 -y -c conda-forge \
python=3.13 \
numpy \
scipy \
gstools \
gstools-cython \
emcee \
hankel \
meshio \
pyevtk \
pip
Install gstools_core:
conda activate gstools-rust-repro-py313
python -m pip install gstools_core
Create and execute the following Rust variogram smoke test as rust_variogram_smoke.py:
import importlib.metadata as md
import numpy as np
import gstools as gs
import gstools_core # noqa: F401
def version(name):
try:
return md.version(name)
except md.PackageNotFoundError:
return "not installed"
print(f"python packages:")
print(f" gstools: {version('gstools')}")
print(f" gstools-cython: {version('gstools-cython')}")
print(f" gstools_core: {version('gstools_core')}")
print(f" numpy: {version('numpy')}")
print(f" scipy: {version('scipy')}")
gs_config = (
gs.config._GSTOOLS_CORE_AVAIL,
gs.config.USE_GSTOOLS_CORE,
gs.config.NUM_THREADS,
)
try:
gs.config._GSTOOLS_CORE_AVAIL = True
gs.config.USE_GSTOOLS_CORE = True
gs.config.NUM_THREADS = 2
x = np.linspace(0.0, 10.0, 12)
y = np.linspace(0.0, 5.0, 12)
field = np.sin(x) + np.cos(y)
bins = np.linspace(0.0, 8.0, 6)
result = gs.vario_estimate(
(x, y),
field,
bins,
mesh_type="unstructured",
return_counts=True,
)
finally:
(
gs.config._GSTOOLS_CORE_AVAIL,
gs.config.USE_GSTOOLS_CORE,
gs.config.NUM_THREADS,
) = gs_config
print("Rust variogram smoke: PASS")
print(result)
The results I've got in this case was:
python packages:
gstools: 1.7.0
gstools-cython: 1.2.0
gstools_core: 1.2.0
numpy: 2.4.6
scipy: 1.17.1
Rust variogram smoke: PASS
Python 3.14 Suspected Failure
Create the Python 3.14 environment:
conda create -n gstools-rust-repro-py314 -y -c conda-forge \
python=3.14 \
numpy \
scipy \
gstools \
gstools-cython \
emcee \
hankel \
meshio \
pyevtk \
pip
Install gstools_core:
conda activate gstools-rust-repro-py314
python -m pip install gstools_core
Run the same smoke test:
python rust_variogram_smoke.py
In this case the result was:
python packages:
gstools: 1.7.0
gstools-cython: 1.2.0
gstools_core: 1.2.0
numpy: 2.4.6
scipy: 1.17.1
[1] 61058 segmentation fault python
As mentioned above, I am not yet sure why the Rust backend fails with Python 3.14. For now, I have decided to use only the Cython backend in the benchmarking workflow until this can be investigated and resolved.
The previous GitHub Actions workflow did not check Rust backend compatibility, so I think this may be the first time this issue has surfaced in CI.
How should we proceed with this? Who would be the best person to investigate or own this issue? Also, should Python 3.14 Rust-backend compatibility be treated as a priority?
Hi,
While creating and testing the GitHub Actions workflow for GSTools benchmarking , I noticed that the Rust backend through
gstools_coresegfaults with Python 3.14. The same minimal variogram smoke test works with any other version of python from 3.11 to 3.13 Python.I am not sure yet whether this is caused by Python 3.14 compatibility, the
gstools_corewheel/build, or something else. Below I show how to reproduce the error I've got.Python 3.13 Control
Create an environment:
Install
gstools_core:Create and execute the following Rust variogram smoke test as
rust_variogram_smoke.py:The results I've got in this case was:
Python 3.14 Suspected Failure
Create the Python 3.14 environment:
Install
gstools_core:Run the same smoke test:
In this case the result was:
As mentioned above, I am not yet sure why the Rust backend fails with Python 3.14. For now, I have decided to use only the Cython backend in the benchmarking workflow until this can be investigated and resolved.
The previous GitHub Actions workflow did not check Rust backend compatibility, so I think this may be the first time this issue has surfaced in CI.
How should we proceed with this? Who would be the best person to investigate or own this issue? Also, should Python 3.14 Rust-backend compatibility be treated as a priority?