Fri 21 Oct 2016 09:09:40 PM UTC, comment #2:
I had a closer look and found the source of the problem, it is now fixed and has been pushed to the main repository. From the commit message:
The `data' element of Table's `outcolumn' structure (in `bin/table/main.h') has a `void *' type to allow various types. However, to allocate space for the output column we were using the `sizeof' operator on it! This would give a size of 1 and would cause a crash some systems.
In the previous commit (5c41564: New function to return the size of FITS datatype), a new function was added to the Gnuastro FITS functions to return the number of bytes in each datatype. With that function, the datatype's size is now also stored in the `outcolumn' structure and the allocation is done based on that.
|
Sat 15 Oct 2016 12:59:05 AM UTC, original submission:
After inspecting the output of the GNU Hydra for Gnuastro 0.2, it was interesting to see issues errors on 32-bit systems.
The first thing that grabs most attention are the numerous warnings are for using `%lu' for size_t values. So in This commit, `%lu' was replaced with `%zu' (from C99 for dealing with `size_t' on both 32-bit and 64-bit systems).
After compilation and in `make check' the two `table/asciitobinary.sh' and `table/binarytoascii.sh' have failed. Alan Lefor also kindly tested it on his 32-bit Raspberry Pi and was able to reproduce this failure. The second depends on the first, so fixing the error in the first will probably fix the second failure too.
So I tried valgrind on `table/asciitobinary.sh' and was surprized to see multiple cases of invalid reads and writes (see below). These invalid reads and writes are probably causing this failure on 32-bit systems and are somehow not an issue on 64-bit systems. But we have to fix them any way.
I currently don't have time to look into them. But if anyone has the chance to look into this it would be great.
|