Opened 15 years ago
Closed 15 years ago
#2960 closed defect (fixed)
Lanczos and CubicSpline resampler buffer error on 2x2 images
Reported by: | warmerdam | Owned by: | Even Rouault |
---|---|---|---|
Priority: | high | Milestone: | 1.6.1 |
Component: | Algorithms | Version: | 1.6.0 |
Severity: | normal | Keywords: | warp api lanczos |
Cc: | sprice, dron, Even Rouault, chaitanya |
Description
The following command:
gdalwarp -r lanczos test.tif testwarp.tif
on the attached file produces the following valgrind report on linux and in some cases crashes gdalwarp on windows.
==7974== Invalid read of size 2 ==7974== at 0x550E86D: GWKGetPixelRow(GDALWarpKernel*, int, int, int, double*, double*, double*) (gdalwarpkernel.cpp:1195) ==7974== by 0x5510068: GWKResample(GDALWarpKernel*, int, double, double, double*, double*, double*, GWKResampleWrkStruct const*) (gdalwarpkernel.cpp:2049) ==7974== by 0x5510CF3: GWKGeneralCase(GDALWarpKernel*) (gdalwarpkernel.cpp:2483) ==7974== by 0x55115DB: GDALWarpKernel::PerformWarp() (gdalwarpkernel.cpp:660) ==7974== by 0x55132EF: GDALWarpOperation::WarpRegionToBuffer(int, int, int, int, void*, GDALDataType, int, int, int, int) (gdalwarpoperation.cpp:1579) ==7974== by 0x5513ACB: GDALWarpOperation::WarpRegion(int, int, int, int, int, int, int, int) (gdalwarpoperation.cpp:1186) ==7974== by 0x55143A9: GDALWarpOperation::ChunkAndWarpImage(int, int, int, int) (gdalwarpoperation.cpp:659) ==7974== by 0x406B31: main (gdalwarp.cpp:933) ==7974== Address 0xAF64478 is 0 bytes after a block of size 16 alloc'd ==7974== at 0x4C21C16: malloc (vg_replace_malloc.c:149) ==7974== by 0x54EA912: VSIMalloc (cpl_vsisimple.cpp:300) ==7974== by 0x5512820: GDALWarpOperation::WarpRegionToBuffer(int, int, int, int, void*, GDALDataType, int, int, int, int) (gdalwarpoperation.cpp:1337) ==7974== by 0x5513ACB: GDALWarpOperation::WarpRegion(int, int, int, int, int, int, int, int) (gdalwarpoperation.cpp:1186) ==7974== by 0x55143A9: GDALWarpOperation::ChunkAndWarpImage(int, int, int, int) (gdalwarpoperation.cpp:659) ==7974== by 0x406B31: main (gdalwarp.cpp:933)
Attachments (1)
Change History (7)
by , 15 years ago
comment:1 by , 15 years ago
Priority: | normal → high |
---|
Chaitanya,
This problem is crashing one of the buildbot slaves on win32, so we want at least a work around for the issue promptly. I would like you to review the svn logs and other materials to determine who is responsible for the lanczos resampler and at least add them as a cc: on this ticket, and possibly turn the issue over to them after some preliminary work around.
comment:2 by , 15 years ago
Cc: | added |
---|---|
Status: | new → assigned |
So far I was not able to reproduce any crash in Linux or Windows. I used VC++8.0 on WinXP(32bit) for building. Maybe the error occurs with the buildbot with the VC++7.1 compiler. I don't have 7.1.
For now I am just going to review the 'invalid read of size 2' and 'memory block length' errors reported in valgrind. I am not sure where this might lead me.
comment:3 by , 15 years ago
There is no need to reproduce the crash as long as you can reproduce the valgrind report which is, as far as I know, the same issue in a more reproducable form.
comment:4 by , 15 years ago
I did get the valgrind report. I didn't get the error with other CInt16 .tif files. I tried to trace back the error. So far, no good.
comment:5 by , 15 years ago
Owner: | changed from | to
---|---|
Status: | assigned → new |
comment:6 by , 15 years ago
Cc: | added; removed |
---|---|
Milestone: | → 1.6.1 |
Resolution: | → fixed |
Status: | new → closed |
Summary: | CInt16 Lanczos resampler buffer error → Lanczos and CubicSpline resampler buffer error on 2x2 images |
Version: | unspecified → 1.6.0 |
This error occurs in corner cases of Seth Price's optimizations (#2327, r15273). At line 2037 of gdalwarpkernel.cpp, we checked that we will not try to read before OR after the source array, but when we have a small image and an algorithm with a big enough radius, the computed min and max indices can be both out of bounds. So just removing the 'else' in the 'else if' fixes the issue. This error occured with any data-type, and with cubic splice resampling too. I don't think that it could occur for "real-life" images.
input CInt16 file crashing resampler.