Opened 18 years ago
Closed 17 years ago
#970 closed defect (fixed)
OGRMakeWktCoordinate overflow
Reported by: | warmerdam | Owned by: | Mateusz Łoskot |
---|---|---|---|
Priority: | normal | Milestone: | 1.4.2 |
Component: | OGR_SF | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: | warmerdam |
Description (last modified by )
From Carlos A. Rueda <carueda@…>
I have just found that some "normal" double values make OGRMakeWktCoordinate to generate a segmentation fault because the internal char arrays are too small for the sprintf formatting. Below is a small program that demonstrates the problem:
$ g++ -Wall wktcoordbug.cc -lgdal $ ./a.out A extreme but normal double value = 0xffffffffffefffff printed with %g = -1.79769e+308 isnormal(value) returns 1 printed with %.15f, the format used by OGRMakeWktCoordinate, = -179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000000000000 Segmentation fault
Note: I made the test on a liitle-endian machine.
///////////////// wktcoordbug.cc /////////////////////// // OGRMakeWktCoordinate bug #include "ogr_geometry.h" #include "ogr_p.h" #include <cstdio> #include <cmath> using namespace std; int main(int argc, char ** argv) { printf("A extreme but normal double value = 0xffffffffffefffff\n"); long dd[2] = { 0xffffffff, 0xffefffff }; double value = *((double*) dd); printf(" printed with %%g = %g\n", value); printf(" isnormal(value) returns %d\n", isnormal(value)); printf(" printed with %%.15f, the format used by OGRMakeWktCoordinate, = %.15f\n", value); // now, the bug: char szCoordinate[80]; // as in OGRPoint::exportToWkt OGRMakeWktCoordinate(szCoordinate, value, 0.0, 0.0, 2); // we dont get this far -> segfault! return 0; }
Carlos
Change History (6)
comment:1 by , 17 years ago
Cc: | added |
---|---|
Description: | modified (diff) |
Milestone: | → 1.4.2 |
Owner: | changed from | to
Priority: | high → normal |
comment:2 by , 17 years ago
Description: | modified (diff) |
---|
comment:3 by , 17 years ago
Status: | new → assigned |
---|
Frank,
The sample program Carlos attached to this report still fails with core dump.
mloskot:~/dev/gdal/bugs/970$ ./test A extreme but normal double value = 0xffffffffffefffff printed with %g = -1.79769e+308 isnormal(value) returns 1 printed with %.15f, the format used by OGRMakeWktCoordinate, = -179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.000000000000000 OGR: Yow! Got this big result in OGRMakeWktCoordinate() 0 0 *** stack smashing detected ***: ./test terminated Aborted (core dumped)
The comment for OGRMakeWktCoordinate() function says:
Currently a new point should require no more than 64 characters barring the X or Y value being extremely large.
and XYZ buffers are set to 40 chars each.
Now, the OGRPoint::exportToWkt() uses buffer long for 2 x 40 chars, so it's shorter than the target buffer assumed in the OGRMakeWktCoordinate().
Are there any new assumptions regarding coordinates lenght?
The most obvious solution I see is to increase target buffer for the coordinates output to at leaste 120 characters.
comment:6 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Added test ogr_wkbwkt_geom_bigexponents() to check the fix for this ticket (r11442).
Mateusz,
I think this might already have been dealt with. Could you try and reproduce with 1.4.1?