Repository navigation
Test failures in parallel thin_plate_spline tests #8212
Description
Description:
Notice current test failure at https://github.com/matthew-brett/scikit-image/actions/runs/26818776702/job/79067833098
This appears to be due to variability in the output from Scipy, when running in parallel threads.
Below is Cursor's analysis:
What the failure actually shows
• Only fails on Python 3.14 free-threaded with pytest-run-parallel --parallel-threads=4
• Passes on local 3.12
• In the failing test, from_estimate + warp succeeds, then estimate + warp fails
• Both paths call the same _estimate implementation:
# from_estimate
tf = cls()
tf._estimate(src, dst)
# estimate (deprecated)
return self._estimate(src, dst) is None
Locally, those produce identical _spline_mappings and identical warp output.
So this doesn't look like a logic bug in “estimation vs from_estimate.” It looks like
environment- or timing-sensitive behavior on 3.14t under parallel test execution.
Way to reproduce:
No response
Activity
stefanv commentedon Jun 12, 2026
Looks like SciPy's pre-filtering is not thread-safe. For now, I disabled in the test suite to run in parallel.
stefanv commentedon Jun 12, 2026
We should double check which code path is followed: if this uses our internal warping code, the fault is in skimage, otherwise in
scipy.ndimage'smap_coordinates. It would make slightly more sense for the error to be in the latter, but I'd have to check.stefanv commentedon Jun 12, 2026
Looks like we do go via the ndimage path.
Asked Claude to investigate, and it seems to say that even
np.dotis not thread-safe. Is that possible?!@ngoldbaum would probably know this off-hand.
ngoldbaum commentedon Jun 13, 2026
This is an OpenBLAS bug I think, see numpy/numpy#31618 and OpenMathLib/OpenBLAS#5836
kumaraditya303 commentedon Jul 24, 2026
I think this is fixed now with OpenMathLib/OpenBLAS#5876
Pin BLAS threads in the free-threaded parallel test run