1.5: test_square_with_point fails on 32 bit

[olebole]

Hi,

sorry for bothering you again with a failures: On all 32 bit architectures (i386, but also ARM, MIPS, PowerPC etc.), test_square_with_point fails (seems to crash):

============================= test session starts ==============================
platform linux2 -- Python 2.7.13rc1, pytest-2.8.3, py-1.4.30, pluggy-0.3.1 -- /usr/bin/python2.7
cachedir: ../.cache

Running tests with Astropy version 1.2.1.
Running tests in lib.linux-i686-2.7/drizzle docs.

Date: 2016-12-08T09:33:22

Platform: Linux-3.16.0-4-amd64-i686-with-debian-stretch-sid

Executable: /usr/bin/python2.7

Full Python Version: 
2.7.13rc1 (default, Dec  4 2016, 14:12:39) 
[GCC 6.2.1 20161124]

encodings: sys: ascii, locale: ANSI_X3.4-1968, filesystem: ANSI_X3.4-1968, unicode bits: 20
byteorder: little
float info: dig: 15, mant_dig: 15

Numpy: 1.11.2
Scipy: not available
Matplotlib: not available
h5py: not available
Pandas: not available

rootdir: /tmp/drizzle-test-dKEuQp, inifile: setup.cfg
collecting ... collected 26 items

drizzle/util.py::drizzle.util.parse_extn PASSED
drizzle/data/README.rst PASSED
drizzle/tests/test_cdrizzle.py::test_cdrizzle utest_map_lookup_01 ............................................... PASS
utest_map_lookup_02 ............................................... PASS
[...]
utest_doblot_02 ................................................... PASS

----------------------------------------------------------------------------

PASSED (35/35 tests in 0.224743s)
PASSED
drizzle/tests/test_drizzle.py::test_square_with_point debian/rules:14: recipe for target 'test-python2.7' failed
make[1]: *** [test-python2.7] Error 245

[bernie-simon]

On Dec 8, 2016, at 4:59 AM, Ole Streicher ***@***.***> wrote: sorry for bothering you again with a failures: On all 32 bit architectures (i386, but also ARM, MIPS, PowerPC etc.), test_square_with_point fails (seems to crash):

The code will be rewritten yet again, but not today, as I have more pressing issues. I just needed to get something more correct than version 1.4 out before the end of the day and so did the quickest thing.

[olebole]

OK; however here is what I found out so far:

The problem is that shrink_segment() calls get_pixmap(pixmap, pix[0], pix[1]);, where pix[0] may be -1. get_pixmap() is a macro that translates to PyArray_GETPTR3(pixmap, ypix, xpix, 0);, which then returns a pointer that may not dereferenced.

I did not check this with 64 bit; however it looks like that it may be buggy there as well (just hidden).

[bernie-simon]

On Dec 8, 2016, at 8:50 AM, Ole Streicher ***@***.***> wrote: OK; however here is what I found out so far: The problem is that shrink_segment() calls get_pixmap(pixmap, pix[0], pix[1]);, where pix[0] may be -1. get_pixmap() is a macro that translates to PyArray_GETPTR3(pixmap, ypix, xpix, 0);, which then returns a pointer that may not dereferenced. I did not check this with 64 bit; however it looks like that it may be buggy there as well (just hidden).

Thanks, I will revisit shrink_segment, perhaps tomorrow.

[mcara]

I know this is very old. Is this still an issue? or can I close this issue?