[1.4.0/1.4.1] Bus error on 32-bit ARM platform

[olebole]

Hi,

I am the Debian maintainer of sep, and tried to update our Debian sep package to 1.4.0 (and later to 1.4.1).

However, when trying to run the test, I observer a Bus error on our "armhf" platform (ARM CPU, ABI 7, 32 bit, hard float):

============================= test session starts ==============================
platform linux -- Python 3.13.2, pytest-8.3.4, pluggy-1.5.0
rootdir: /home/olebole/sep
configfile: pyproject.toml
plugins: typeguard-4.4.2, cov-5.0.0, remotedata-0.4.1, astropy-0.11.0, hypothesis-6.125.2, mock-3.14.0, astropy-header-0.2.2, filter-subpackage-0.2.0, arraydiff-0.6.1, doctestplus-1.4.0
collected 26 items

test.py Fatal Python error: Bus error

Current thread 0xf7ede020 (most recent call first):
  File "/home/olebole/sep/test.py", line 214 in test_vs_sextractor
  File "/usr/lib/python3/dist-packages/_pytest/python.py", line 159 in pytest_pyfunc_call
  […]

Backtracing in a debugger (optimization disables; with source from 1.4.1) gives:

(gdb) bt
#0  0xf7acf776 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0xf7b12798 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#2  0xf7addf22 in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#3  <signal handler called>
#4  __pyx_pf_3sep_2sum_circle (__pyx_self=0xf58749e8, __pyx_v_data=0xf56044d0, 
    __pyx_v_x=0xf56047a0, __pyx_v_y=0xf5604620, __pyx_v_r=0xf5604740, 
    __pyx_v_var=0x461104 <_Py_NoneStruct>, __pyx_v_err=0xf591f3f0, 
    __pyx_v_gain=0x461104 <_Py_NoneStruct>, 
    __pyx_v_mask=0x461104 <_Py_NoneStruct>, __pyx_v_maskthresh=0, 
    __pyx_v_seg_id=0xf5604710, __pyx_v_segmap=0x461104 <_Py_NoneStruct>, 
    __pyx_v_bkgann=0x461104 <_Py_NoneStruct>, __pyx_v_subpix=5) at sep.c:29387
#5  0xf571826c in __pyx_pw_3sep_3sum_circle (__pyx_self=0xf58749e8, 
    __pyx_args=0xf7c8ccd4, __pyx_nargs=4, __pyx_kwds=0xf594b3d0) at sep.c:28782
#6  0xf5789cb2 in __Pyx_CyFunction_Vectorcall_FASTCALL_KEYWORDS (
    func=0xf58749e8, args=0xf7c8ccd4, nargsf=2147483652, kwnames=0xf594b3d0)
    at sep.c:49373
#7  0x0008d1d2 in PyObject_Vectorcall ()
#8  0x000a413c in _PyEval_EvalFrameDefault ()
#9  0x0008e15e in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

sep.c:29387 is

     /* "sep.pyx":1009                                                         
 *         while np.PyArray_MultiIter_NOTDONE(it):                              
 *                                                                              
 *             status = sep_sum_circle(             # <<<<<<<<<<<<<<            
 *                 &im,                                                         
 *                 (<double*>np.PyArray_MultiIter_DATA(it, 0))[0],              
 */
      __pyx_v_status = sep_sum_circle((&__pyx_v_im), (((double *)PyArray_MultiI\
ter_DATA(__pyx_v_it, 0))[0]), (((double *)PyArray_MultiIter_DATA(__pyx_v_it, 1)\
)[0]), (((double *)PyArray_MultiIter_DATA(__pyx_v_it, 2))[0]), (((int *)PyArray\
_MultiIter_DATA(__pyx_v_it, 3))[0]), __pyx_v_subpix, 0, ((double *)PyArray_Mult\
iIter_DATA(__pyx_v_it, 4)), ((double *)PyArray_MultiIter_DATA(__pyx_v_it, 5)), \
(&__pyx_v_area1), ((short *)PyArray_MultiIter_DATA(__pyx_v_it, 6)));

which actually points to

sep/sep.pyx

Lines 1009 to 1019 in 4c3acca

	status = sep_sum_circle(
	&im,
	(<double*>np.PyArray_MultiIter_DATA(it, 0))[0],
	(<double*>np.PyArray_MultiIter_DATA(it, 1))[0],
	(<double*>np.PyArray_MultiIter_DATA(it, 2))[0],
	(<int*>np.PyArray_MultiIter_DATA(it, 3))[0],
	subpix, 0,
	<double*>np.PyArray_MultiIter_DATA(it, 4),
	<double*>np.PyArray_MultiIter_DATA(it, 5),
	&area1,
	<short*>np.PyArray_MultiIter_DATA(it, 6))

A similar crash (on sep.pyx:1939) happens on test_masked_segmentation_measurements(). If I skip both tests, the other tests pass without problems.

Do you have any idea what this could be? The platform armhf is known to be sensible for non-aligned data access. On all other platforms, the package builds fine (and the tests pass).
This problem did not appear under the older versions (up to 1.2.1)
A full build log, but without the gdb stack trace is here.