IMIO bug in 2.16 when using boundary extension
James Turner wrote on Feb 10, 2013
This is similar to the apextract bug I reported a few days ago, but seems to be new in 2.16.
One of our tests was crashing with an overflow error after imshift had introduced corrupt pixel values of 10^26 in the first row of an image. I've tracked this to another (sometimes) uninitialized variable in the file imio/imrbpx.x.
The variable "ncp" is used at L123 of imrbpx to increment the array index "op", but its value is only set when the "if" condition at L98 has not been met and the "else" has been executed. For negative shifts (at least this case), the "if" gets executed on the first loop iteration, so ncp is uninitialized. The value of ncp then gets corrected by the else block at the next iteration and (for me) that value then gets retained between one imrbpx call and the next, thus only the first line of the image gets corrupted.
I believe I have fixed this in our installation by moving "ncp = sz_pixel" at L102 to L75 (above the "do i = 1,3" loop); our imshifted image now looks fine.
Thanks,
James.
One of our tests was crashing with an overflow error after imshift had introduced corrupt pixel values of 10^26 in the first row of an image. I've tracked this to another (sometimes) uninitialized variable in the file imio/imrbpx.x.
The variable "ncp" is used at L123 of imrbpx to increment the array index "op", but its value is only set when the "if" condition at L98 has not been met and the "else" has been executed. For negative shifts (at least this case), the "if" gets executed on the first loop iteration, so ncp is uninitialized. The value of ncp then gets corrected by the else block at the next iteration and (for me) that value then gets retained between one imrbpx call and the next, thus only the first line of the image gets corrupted.
I believe I have fixed this in our installation by moving "ncp = sz_pixel" at L102 to L75 (above the "do i = 1,3" loop); our imshifted image now looks fine.
Thanks,
James.
James Turner wrote on Feb 10, 2013
It occurs to me that my fix probably isn't quite correct on 64-bits, is it? I think the couple of lines that double the pixel size if "SZ_INT != SZ_INT32" at L108 would also need moving.
Mike Fitzpatrick wrote on Feb 10, 2013
Hi James,
I agree there is an initialization problem with the 'ncp' variable and have fixed this in the next release. The 'SZ_INT != SZ_INT32' check has to do with converting between the integer pixels in the disk file (which are always 32-bit) and that used in the imio code (where integers can be 64-bit and so need packing/unpacking when moving between disk and memory), I believe this part of the code is correct.
-Mike
I agree there is an initialization problem with the 'ncp' variable and have fixed this in the next release. The 'SZ_INT != SZ_INT32' check has to do with converting between the integer pixels in the disk file (which are always 32-bit) and that used in the imio code (where integers can be 64-bit and so need packing/unpacking when moving between disk and memory), I believe this part of the code is correct.
-Mike
James Turner wrote on Feb 10, 2013
That's great, thanks.
The reason I queried the SZ_INT part was just that it also changes the value of ncp, which I believe would then get used for incrementing the next of the 3 iterations by a different amount from the previous iteration(?) -- but I haven't really tested that behaviour as we're always using 32-bit binaries so I only mentioned it in case my previous suggestion was incomplete/misleading.
By the way, I have seen some corruption due to this in a different test that was over the whole image rather than just the first row, which also went away after initializing ncp, just in case you get similar reports...
Cheers,
James.
The reason I queried the SZ_INT part was just that it also changes the value of ncp, which I believe would then get used for incrementing the next of the 3 iterations by a different amount from the previous iteration(?) -- but I haven't really tested that behaviour as we're always using 32-bit binaries so I only mentioned it in case my previous suggestion was incomplete/misleading.
By the way, I have seen some corruption due to this in a different test that was over the whole image rather than just the first row, which also went away after initializing ncp, just in case you get similar reports...
Cheers,
James.
Last post on Feb 10, 2013