For a request of a teacher, I need to debug a project finished in 2001. It's a typical overflow problem when seeing it. The program is an image compressor, but especially for remote sensing images.
The symptom is that when the width and height of image both exceed some value above 16000, the compressed result is not right. When decompress the result to restore the uncompressed format, it can't be opened.
First, I try to verify the data field is right, if it does, then the most probable taken place should be the tag field in field. Using Photoshop to read as a RAW format, the image is correctly shown, luckily! But tring to find the wrong tag require careful and thorough work. Comparing the problem image and original image, I trace the tag field directly in hex mode, two tag field is different in sixteen. the offset and bytecount is very strange. Then, I can confirm that the overflow must have happened in the related code. Of course I can't imagine that 16384 equals 2^14, because the notorious overflow point is freqently happened at 2^8, 2^16 and 2^32. But when I find the shift left operation, I know I find it. There is a shift left operation which shift 2 bits, when the width and height exceeds 2^14, this operation leads to overflow.
Except the corrections above, there still another place should correct - a short integer. We still need more considerations when design our programs, and predict the values it possibly take. In this case, the coder didn't foresee that the width and height can taken such large value, but he forgot the remote sensing image did have this kind of dimension.
评论