Opened 14 years ago

Closed 13 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 Mateusz Łoskot)

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 Changed 13 years ago by warmerdam

Cc: warmerdam added
Description: modified (diff)
Milestone: 1.4.2
Owner: changed from warmerdam to Mateusz Łoskot
Priority: highnormal

Mateusz,

I think this might already have been dealt with. Could you try and reproduce with 1.4.1?

comment:2 Changed 13 years ago by Mateusz Łoskot

Description: modified (diff)

comment:3 Changed 13 years ago by Mateusz Łoskot

Status: newassigned

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:4 Changed 13 years ago by Mateusz Łoskot

Sorry, I'm wrong with the idea of making the buffer size bigger.

comment:5 Changed 13 years ago by Mateusz Łoskot

Fixed in r11440 and r11441.

comment:6 Changed 13 years ago by Mateusz Łoskot

Resolution: fixed
Status: assignedclosed

Added test ogr_wkbwkt_geom_bigexponents() to check the fix for this ticket (r11442).

Note: See TracTickets for help on using tickets.