Repository navigation
FFT segfault #1362
Description
import galsim
fwhm = 0.00012892424082577847
e1 = 0.0
e2 = 0.0
dx = -0.24762100026331102
dy = 0.3718091783120656
nx = ny = 90
scale = 0.2
print(f"Attempting drawImage with {fwhm=}, {e1=}, {e2=}, {dx=}, {dy=}, {nx=}, {scale=}")
obj = galsim.Kolmogorov(fwhm=fwhm).shear(e1=e1, e2=e2).shift(dx, dy)
img = obj.drawImage(nx=nx, ny=ny, scale=scale)
print(f"ok, sum={img.array.sum():.6f}")This segfaults with galsim 2.8.4 for me at USDF. Certainly my fault for letting an optimizer try to draw such a thing, but shouldn't the failure be more graceful than a segfault?
Tail of the traceback is
File "/sdf/group/rubin/sw/conda/envs/lsst-scipipe-13.0.0/lib/python3.13/site-packages/galsim/image.py", line 795 in _wrap
File "/sdf/group/rubin/sw/conda/envs/lsst-scipipe-13.0.0/lib/python3.13/site-packages/galsim/gsobject.py", line 1997 in drawFFT_finish
File "/sdf/group/rubin/sw/conda/envs/lsst-scipipe-13.0.0/lib/python3.13/site-packages/galsim/gsobject.py", line 2045 in drawFFT
File "/sdf/group/rubin/sw/conda/envs/lsst-scipipe-13.0.0/lib/python3.13/site-packages/galsim/gsobject.py", line 1813 in drawImage
Activity
rmjarvis commentedon Jun 10, 2026
Oof. Two in one day. Brenna Wells reported a seg fault in Piff (most likely due to GalSim as well I assume) today too.
FWIW, I think yours is due to an extremely large FFT. Here is the output I get running this script:
So yeah. This used to raise an exception for too large an FFT. This is the downside of not requiring people to explicitly set maximum_fft_size to avoid the error is now sometimes there is just a warning and then maybe catastrophe. Is this a win for the average user or not?
taranu commentedon Sep 24, 2026
Personally, I didn't realize galsim.errors.raise_fft_size_error existed until a few days ago, and we definitely will set that to True in source_injection. Is the average user doing batch processing? I guess not.
rmjarvis commentedon Sep 24, 2026
The change happened here:
#1341
Multiple users were complaining about having to regularly increase the maximum_fft_size for very reasonable profiles on modern systems that could easily handle it. So I was persuaded at the time to switch it to just emitting a warning, rather than an error. But now I'm starting to second guess that decision. You're not the only person to have had a problem due to a large FFT borking their system since making that change.
taranu commentedon Sep 24, 2026
To be clear, I didn't run into any segfaults like Josh did - I just noticed the slow runtime on a high memory node. We didn't notice the change because we didn't have a unit test checking for large FFT errors, but we are adding one.