[GRASS-dev] g.region -g crashes in a latlon location

[Glynn Clements]

Yann Chemin wrote:

> This is on my system:

> Program received signal SIGSEGV, Segmentation fault.
> 0x00007fda5b45ca7e in sincos () from /usr/lib/libgdal1.5.0.so.1

Whoah; GDAL?

sincos() is defined in libm:

       void sincos(double x, double *sin, double *cos);

But gdal has its own version in frmts/hdf4/hdf-eos/GDapi.c (GDapi.c? 
That was in Maciej's report):

#if !defined(HP9000) && !defined(DEC_ALPHA)
void
sincos(double val, double *sin_val, double *cos_val)
{
    *sin_val = sin(val);
    *cos_val = cos(val);
    return;
}
#endif

On my system, nearly all of the symbols in libm are weak, so
definitions in other libraries can override them, even for use within
libm.

I note that G_set_geodesic_distance_lat2() computes both sin() and
cos() for two angles:

    stm = sin(tm);
    ctm = cos(tm);
    sdtm = sin(dtm);
    cdtm = cos(dtm);

That could explain why it only happens with optimisation enabled: the
compiler notices that it needs both sin() and cos() of the same angle,
and uses sincos() instead.

Similarly, if GDAL was compiled with optimisation, GDAL's sincos()
calculates both sin() and cos() of its argument (well that's the whole
point of the function), so the compiler optimises GDAL's sincos() to
sincos(), resulting in infinite reecursion.

I'm fairly sure that's what is going on here.

I think that the ultimate solution would be for GDAL to be a bit more
careful about defining sincos, i.e. have configure actually check
whether libm defines sincos() rather than assuming that it only exists
on specific platforms.

-- 
Glynn Clements <glynn at gclements.plus.com>