mincreshape - "Can't allocate 135168 bytes"

[andrewjanke]

Another from the dark recesses of minc-users, not sure of this ones veracity as a test dataset wasn't provided.

---

I am gettign a strange error from mincreshape when downsampling a dataset.
This is what I have:

mincinfo T320.mnc
file: T320.mnc
image: signed__ short -2048 to 3062
image dimensions: time zspace yspace xspace
dimension name length step start
-------------- ------ ---- -----
time 12 1 0
zspace 320 0.5 -539.75
yspace 512 -0.461 107.894
xspace 512 -0.461 117.894

And I do:

mincreshape -clobber -dimsize xspace=128 -dimsize yspace=128 -dimsize
zspace=128 T320.mnc t.mnc
Copying chunks:.(from miicv_get): Can't allocate 135168 bytes
(and I have several gigs of RAM free)

But it works with 16 slices:

mincreshape -clobber -dimsize xspace=128 -dimsize yspace=128 -dimsize
zspace=16 T320.mnc t.mnc
(OK)

Googling "Can't allocate 135168 bytes" leads to some results, but not
nothing that is an obvious fix to me.

I am on Fedora 17 with
mincreshape -version
program: 2.1.20
libminc: 2.1.20
netcdf : 4.2 of Sep 5 2012 22:51:46 $
HDF5 : 1.8.8

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.0/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla--enable-bootstrap
--enable-shared --enable-threads=posix
--enable-checking=release --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto
--enable-plugin --enable-initfini-array --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC)

[andrewjanke]

so, it looks like there is a bug in mincreshape code. It works if new dimension size is integer fraction of input dimension size. I.e
mincreshape -dimsize xspace=128 -dimsize yspace=128 -dimsize zspace=160 20120912tt.mnc output.mnc - works

however

mincreshape -dimsize xspace=128 -dimsize yspace=128 -dimsize zspace=159 20120912tt.mnc output.mnc

fails as in your example.

So, obvious workaround would be to use integer scaling for now.

Information for Andrew:

I traced error down to image_conversion.c:MI_icv_access where , somehow
icvp->derv_dim_off is filled with positive values which lead to negative size of dimension in MI_icv_coords_tovar function.

[rdvincent]

I've developed a possible fix for this. I found that valgrind complains bitterly about mincreshape in many cases, so this problem is probably a symptom of heap corruption. The issue is deep in the ICV code, which does not correctly verify that the calculated dimension offsets lie within the actual allocated space in the arguments. So miicv_get() and miicv_put() can easily scribble outside the lines, especially when operating on subslabs of the full image. I have implemented a check which seems to prevent the problem while allowing existing test code to work as before.

[andrewjanke]

Thanks Bert,

The original reporter of this was Soren Christensen, I see if I can get him to supply the test case.

a