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

Maciej_Sieczka2 · July 20, 2008, 4:21pm

I have just noticed that g.region -g or -p crashes in a latlon location. Example:

$ g.proj -p
-PROJ_INFO-------------------------------------------------
name : Latitude-Longitude
datum : wgs84
towgs84 : 0.000,0.000,0.000
proj : ll
ellps : wgs84
-PROJ_UNITS------------------------------------------------
unit : degree
units : degrees
meters : 1.0

$ gdb g.region
$ run -g

Starting program: /usr/local/grass-6.4.svn/bin/g.region -g
[Thread debugging using libthread_db enabled]
warning: Lowest section in /usr/lib/libicudata.so.38 is .hash at 0000000000000120
[New Thread 0x7f33d2feb710 (LWP 9517)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f33d2feb710 (LWP 9517)]
0x00007f33d130f69e in sincos (val=0.90594848802138783, sin_val=0x7fffda923030,
     cos_val=0x7fffda923028) at GDapi.c:6265
6265 *sin_val = sin(val);
(gdb) bt
#0 0x00007f33d130f69e in sincos (val=0.90594848802138783,
     sin_val=0x7fffda923030, cos_val=0x7fffda923028) at GDapi.c:6265
#1 0x00007f33d130f6a3 in sincos (val=0.90594848802138783,
     sin_val=0x7fffda923060, cos_val=0x7fffda923058) at GDapi.c:6265
#2 0x00007f33d130f6a3 in sincos (val=0.90594848802138783,
     sin_val=0x7fffda923090, cos_val=0x7fffda923088) at GDapi.c:6265
#3 0x00007f33d130f6a3 in sincos (val=0.90594848802138783,
     sin_val=0x7fffda9230c0, cos_val=0x7fffda9230b8) at GDapi.c:6265
#4 0x00007f33d130f6a3 in sincos (val=0.90594848802138783,
     sin_val=0x7fffda9230f0, cos_val=0x7fffda9230e8) at GDapi.c:6265
#5 0x00007f33d130f6a3 in sincos (val=0.90594848802138783,
     sin_val=0x7fffda923120, cos_val=0x7fffda923118) at GDapi.c:6265
#6 0x00007f33d130f6a3 in sincos (val=0.90594848802138783,
     sin_val=0x7fffda923150, cos_val=0x7fffda923148) at GDapi.c:6265
#7 0x00007f33d130f6a3 in sincos (val=0.90594848802138783,
     sin_val=0x7fffda923180, cos_val=0x7fffda923178) at GDapi.c:6265
#8 0x00007f33d130f6a3 in sincos (val=0.90594848802138783,
     sin_val=0x7fffda9231b0, cos_val=0x7fffda9231a8) at GDapi.c:6265
#9 0x00007f33d130f6a3 in sincos (val=0.90594848802138783,
     sin_val=0x7fffda9231e0, cos_val=0x7fffda9231d8) at GDapi.c:6265
#10 0x00007f33d130f6a3 in sincos (val=0.90594848802138783,
     sin_val=0x7fffda923210, cos_val=0x7fffda923208) at GDapi.c:6265
#11 0x00007f33d130f6a3 in sincos (val=0.90594848802138783,
---Type <return> to continue, or q <return> to quit---

(The whole backtrace is all very long.)

What's going on?

Maciek

--
Maciej Sieczka
www.sieczka.org

Maciej_Sieczka2 · July 20, 2008, 4:26pm

Oh, I forgot: GRASS 6.4 SVN r32167, Debian testing amd64.

Glynn_Clements1 · July 20, 2008, 6:47pm

Maciej Sieczka wrote:

I have just noticed that g.region -g or -p crashes in a latlon location.
Example:

0x00007f33d130f69e in sincos (val=0.90594848802138783,
sin_val=0x7fffda923030,
     cos_val=0x7fffda923028) at GDapi.c:6265
6265 *sin_val = sin(val);
(gdb) bt
#0 0x00007f33d130f69e in sincos (val=0.90594848802138783,
     sin_val=0x7fffda923030, cos_val=0x7fffda923028) at GDapi.c:6265
#1 0x00007f33d130f6a3 in sincos (val=0.90594848802138783,
     sin_val=0x7fffda923060, cos_val=0x7fffda923058) at GDapi.c:6265
#2 0x00007f33d130f6a3 in sincos (val=0.90594848802138783,
     sin_val=0x7fffda923090, cos_val=0x7fffda923088) at GDapi.c:6265

(The whole backtrace is all very long.)

When you say "very long", is it actually finite? Or did you give up
before reaching the end?

Because the line which the debugger shows:

6265 *sin_val = sin(val);

doesn't appear to be a recursive call, but the backtrace indicates an
infinite "direct" recursion (i.e. the function calls itself with
exactly the same arguments).

My guess is that the saved frame pointer is actually pointing to the
current frame, i.e. a linked list where "p->next == p".

In any case, this doesn't help identify the real problem. Can you step
through the g.region code from the beginning and find where in
g.region (or the GRASS libraries) that it's going out of control?

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

Maciej_Sieczka2 · July 21, 2008, 7:25am

Glynn Clements pisze:

Maciej Sieczka wrote:

I have just noticed that g.region -g or -p crashes in a latlon
location. Example:

0x00007f33d130f69e in sincos (val=0.90594848802138783, sin_val=0x7fffda923030, cos_val=0x7fffda923028) at GDapi.c:6265 6265 *sin_val = sin(val); (gdb) bt #0 0x00007f33d130f69e in
sincos (val=0.90594848802138783, sin_val=0x7fffda923030,
cos_val=0x7fffda923028) at GDapi.c:6265 #1 0x00007f33d130f6a3 in
sincos (val=0.90594848802138783, sin_val=0x7fffda923060,
cos_val=0x7fffda923058) at GDapi.c:6265 #2 0x00007f33d130f6a3 in
sincos (val=0.90594848802138783, sin_val=0x7fffda923090,
cos_val=0x7fffda923088) at GDapi.c:6265

(The whole backtrace is all very long.)

When you say "very long", is it actually finite? Or did you give up before reaching the end?

The latter. After reaching line #5473 in gdb I gave up.

Because the line which the debugger shows:

6265 *sin_val = sin(val);

doesn't appear to be a recursive call, but the backtrace indicates an
infinite "direct" recursion (i.e. the function calls itself with exactly the same arguments).

My guess is that the saved frame pointer is actually pointing to the current frame, i.e. a linked list where "p->next == p".

In any case, this doesn't help identify the real problem. Can you
step through the g.region code from the beginning and find where in g.region (or the GRASS libraries) that it's going out of control?

If you can tell how to do it I'd try.

Can you reproduce the crash? Anybody else?

Maciek

P.S.

Here's GRASS debug output. Maybe it helps some:

D2/10: G__read_Cell_head
D2/10: G__read_Cell_head_array
D3/10: region item: proj: 3
D3/10: region item: zone: 0
D3/10: region item: north: 51N
D3/10: region item: south: 50N
D3/10: region item: east: 16E
D3/10: region item: west: 15E
D3/10: region item: cols: 1
D3/10: region item: rows: 1
D3/10: region item: e-w resol: 1
D3/10: region item: n-s resol: 1
D3/10: region item: top: 1
D3/10: region item: bottom: 0
D3/10: region item: cols3: 1
D3/10: region item: rows3: 1
D3/10: region item: depths: 1
D3/10: region item: e-w resol3: 1
D3/10: region item: n-s resol3: 1
D3/10: region item: t-b resol: 1
D3/10: G_adjust_Cell_head: epsilon_ns: 0.001, epsilon_ew: 1e-06
D2/10: G__read_Cell_head
D2/10: G__read_Cell_head_array
D3/10: region item: proj: 3
D3/10: region item: zone: 0
D3/10: region item: north: 52:00:01.5N
D3/10: region item: south: 50:59:58.5N
D3/10: region item: east: 17:00:01.5E
D3/10: region item: west: 14:59:58.5E
D3/10: region item: cols: 2401
D3/10: region item: rows: 1201
D3/10: region item: e-w resol: 0:00:03
D3/10: region item: n-s resol: 0:00:03
D3/10: region item: top: 1
D3/10: region item: bottom: 0
D3/10: region item: cols3: 2401
D3/10: region item: rows3: 1201
D3/10: region item: depths: 1
D3/10: region item: e-w resol3: 0:00:03
D3/10: region item: n-s resol3: 0:00:03
D3/10: region item: t-b resol: 1
D3/10: G_adjust_Cell_head: epsilon_ns: 8.32639e-07, epsilon_ew: 1e-06
Segmentation fault

--
Maciej Sieczka
www.sieczka.org

Yann3 · July 21, 2008, 9:22am

I also have g.region -p crashing for about 2 weeks, cannot run tcltk
GUI and wxpython GUI because of that.

it does not say anything, on the segfault sentence...

2008/7/21 Maciej Sieczka <tutey@o2.pl>:

Glynn Clements pisze:

Maciej Sieczka wrote:

I have just noticed that g.region -g or -p crashes in a latlon
location. Example:

0x00007f33d130f69e in sincos (val=0.90594848802138783,
sin_val=0x7fffda923030, cos_val=0x7fffda923028) at GDapi.c:6265 6265
*sin_val = sin(val); (gdb) bt #0 0x00007f33d130f69e in
sincos (val=0.90594848802138783, sin_val=0x7fffda923030,
cos_val=0x7fffda923028) at GDapi.c:6265 #1 0x00007f33d130f6a3 in
sincos (val=0.90594848802138783, sin_val=0x7fffda923060,
cos_val=0x7fffda923058) at GDapi.c:6265 #2 0x00007f33d130f6a3 in
sincos (val=0.90594848802138783, sin_val=0x7fffda923090,
cos_val=0x7fffda923088) at GDapi.c:6265

(The whole backtrace is all very long.)

When you say "very long", is it actually finite? Or did you give up before
reaching the end?

The latter. After reaching line #5473 in gdb I gave up.

Because the line which the debugger shows:

6265 *sin_val = sin(val);

doesn't appear to be a recursive call, but the backtrace indicates an
infinite "direct" recursion (i.e. the function calls itself with exactly
the same arguments).

My guess is that the saved frame pointer is actually pointing to the
current frame, i.e. a linked list where "p->next == p".

In any case, this doesn't help identify the real problem. Can you
step through the g.region code from the beginning and find where in
g.region (or the GRASS libraries) that it's going out of control?

If you can tell how to do it I'd try.

Can you reproduce the crash? Anybody else?

Maciek

P.S.

Here's GRASS debug output. Maybe it helps some:

D2/10: G__read_Cell_head
D2/10: G__read_Cell_head_array
D3/10: region item: proj: 3
D3/10: region item: zone: 0
D3/10: region item: north: 51N
D3/10: region item: south: 50N
D3/10: region item: east: 16E
D3/10: region item: west: 15E
D3/10: region item: cols: 1
D3/10: region item: rows: 1
D3/10: region item: e-w resol: 1
D3/10: region item: n-s resol: 1
D3/10: region item: top: 1
D3/10: region item: bottom: 0
D3/10: region item: cols3: 1
D3/10: region item: rows3: 1
D3/10: region item: depths: 1
D3/10: region item: e-w resol3: 1
D3/10: region item: n-s resol3: 1
D3/10: region item: t-b resol: 1
D3/10: G_adjust_Cell_head: epsilon_ns: 0.001, epsilon_ew: 1e-06
D2/10: G__read_Cell_head
D2/10: G__read_Cell_head_array
D3/10: region item: proj: 3
D3/10: region item: zone: 0
D3/10: region item: north: 52:00:01.5N
D3/10: region item: south: 50:59:58.5N
D3/10: region item: east: 17:00:01.5E
D3/10: region item: west: 14:59:58.5E
D3/10: region item: cols: 2401
D3/10: region item: rows: 1201
D3/10: region item: e-w resol: 0:00:03
D3/10: region item: n-s resol: 0:00:03
D3/10: region item: top: 1
D3/10: region item: bottom: 0
D3/10: region item: cols3: 2401
D3/10: region item: rows3: 1201
D3/10: region item: depths: 1
D3/10: region item: e-w resol3: 0:00:03
D3/10: region item: n-s resol3: 0:00:03
D3/10: region item: t-b resol: 1
D3/10: G_adjust_Cell_head: epsilon_ns: 8.32639e-07, epsilon_ew: 1e-06
D3/10: G_adjust_Cell_head: epsilon_ns: 8.32639e-07, epsilon_ew: 1e-06
Segmentation fault

--
Maciej Sieczka
www.sieczka.org
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin

Glynn_Clements1 · July 21, 2008, 10:22am

Maciej Sieczka wrote:

> In any case, this doesn't help identify the real problem. Can you
> step through the g.region code from the beginning and find where in
> g.region (or the GRASS libraries) that it's going out of control?

If you can tell how to do it I'd try.

$ gdb g.region

break main
run -g

Starting program: /usr/local/src/grass/svn/dist.i686-pc-linux-gnu/bin/g.region -g
...
Breakpoint 1, main (argc=2, argv=0xbfc241a4) at main.c:31
31 int print_flag = 0;

next

35 int row_flag=0, col_flag=0;

Then keep pressing Return (which repeats the last command) until it
crashes.

The crash will probably have occured during a call to some library
function. Set a breakpoint on that function ("break <name>") then type
"run -g" to start again. When it hits the first breakpoint (main),
type "cont". When it hits the second breakpoint, start single-stepping
(next, Return, Return ...) until it crashes.

Repeat this procedure until the crash occurs on a statement which
either isn't a function call or which isn't a GRASS function.

Can you reproduce the crash? Anybody else?

Not me.

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

Maciej_Sieczka2 · July 21, 2008, 11:00am

Glynn Clements pisze:

Maciej Sieczka wrote:

In any case, this doesn't help identify the real problem. Can you
step through the g.region code from the beginning and find where in g.region (or the GRASS libraries) that it's going out of control?

If you can tell how to do it I'd try.

$ gdb g.region

break main
run -g

Starting program: /usr/local/src/grass/svn/dist.i686-pc-linux-gnu/bin/g.region -g
...
Breakpoint 1, main (argc=2, argv=0xbfc241a4) at main.c:31
31 int print_flag = 0;

next

35 int row_flag=0, col_flag=0;

Then keep pressing Return (which repeats the last command) until it
crashes.

Here's the result:

873 if (print_flag)
(gdb)
874 print_window (&window, print_flag);
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0x00007f3fa74b369e in sincos (val=0.90594848802138783, sin_val=0x7fffb0ac7040, cos_val=0x7fffb0ac7038) at GDapi.c:6265
6265 *sin_val = sin(val);
(gdb)

The crash will probably have occured during a call to some library
function. Set a breakpoint on that function ("break <name>") then type
"run -g" to start again. When it hits the first breakpoint (main),
type "cont". When it hits the second breakpoint, start single-stepping
(next, Return, Return ...) until it crashes.

So I did:

(gdb) break print_window
Breakpoint 2 at 0x404380: file printwindow.c, line 9.

<snip>

D3/10: region item: t-b resol: 1
D3/10: G_adjust_Cell_head: epsilon_ns: 8.32639e-07, epsilon_ew: 1e-06

Breakpoint 2, print_window (window=0x7fffd3fd5fe0, print_flag=3) at printwindow.c:9
9 {
(gdb) next
20 if (print_flag & PRINT_SH)
(gdb)
9 {
(gdb)
20 if (print_flag & PRINT_SH)
(gdb)
25 G_format_northing(window->north, north, x);
(gdb)
26 G_format_northing(window->south, south, x);
(gdb)
27 G_format_easting(window->east, east, x);
(gdb)
28 G_format_easting(window->west, west, x);
(gdb)
29 G_format_resolution(window->ew_res, ewres, x);
(gdb)
30 G_format_resolution(window->ew_res3, ewres3, x);
(gdb)
31 G_format_resolution(window->ns_res, nsres, x);
(gdb)
32 G_format_resolution(window->ns_res3, nsres3, x);
(gdb)
33 G_format_resolution(window->tb_res, tbres, x);
(gdb)
34 G_begin_distance_calculations();
(gdb)
37 ew_dist1 =
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0x00007fa1ca1c369e in sincos (val=0.90594848802138783, sin_val=0x7fffd37d7030, cos_val=0x7fffd37d7028) at GDapi.c:6265
6265 *sin_val = sin(val);
(gdb)

Repeat this procedure until the crash occurs on a statement which
either isn't a function call or which isn't a GRASS function.

I don't know how to tell the difference.

Maciek

--
Maciej Sieczka
www.sieczka.org

Glynn_Clements1 · July 21, 2008, 3:43pm

Maciej Sieczka wrote:

>>> In any case, this doesn't help identify the real problem. Can you
>>> step through the g.region code from the beginning and find where in
>>> g.region (or the GRASS libraries) that it's going out of control?
>> If you can tell how to do it I'd try.

Here's the result:

Breakpoint 2, print_window (window=0x7fffd3fd5fe0, print_flag=3) at
printwindow.c:9

(gdb)
37 ew_dist1 =
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0x00007fa1ca1c369e in sincos (val=0.90594848802138783,
sin_val=0x7fffd37d7030, cos_val=0x7fffd37d7028) at GDapi.c:6265
6265 *sin_val = sin(val);
(gdb)

Okay, the full statement is:

ew_dist1 =
G_distance(window->east, window->north, window->west, window->north);

The next step would be to set a breakpoint on G_distance, and repeat.
But I already know that will lead to G_geodesic_distance().

Below that, there isn't actually anything which can cause a segfault.
So, it's very much looking like a broken system.

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

Maciej_Sieczka2 · July 21, 2008, 6:44pm

Glynn Clements pisze:

Below that, there isn't actually anything which can cause a segfault.
So, it's very much looking like a broken system.

Gotcha! I'm using GCC 4.3.1 on amd64 Debian testing. Apparently it
doesn't like GRASS default optimisation flags "-g -O2". When I override
them it with e.g. "-pipe" alone, the segfault is gone.

On another machine (Ubuntu Gutsy amd64) where GCC is 4.1.3, "-g -O2" has
no side effects.

Should GRASS enforce any optimisation flags by default?

Maciek

--
Maciej Sieczka
www.sieczka.org

Yann3 · July 21, 2008, 10:08pm

This is on my system:
857 print_window (&window, print_flag);
(gdb)

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

break print_window gives:

(gdb)
37 ew_dist1 =
(gdb)

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

break G_distance gives:

Breakpoint 3, G_distance (e1=25.075814295277777, n1=41.64570967638889,
e2=21.946861788888889,
n2=41.64570967638889) at distance.c:84
84 {
(gdb)
85 if (projection == PROJECTION_LL)
(gdb)
G_distance (e1=25.075814295277777, n1=41.64570967638889, e2=21.946861788888889,
n2=41.64570967638889) at distance.c:86
86 return G_geodesic_distance (e1, n1, e2, n2);
(gdb)
0x00007f4f967239d8 in G_geodesic_distance@plt () from
/usr/local/grass-7.0.svn/lib/libgrass_gis.so
Current language: auto; currently asm
(gdb)
Single stepping until exit from function G_geodesic_distance@plt,
which has no line number information.
0x00007f4f96722ba8 in ?? () from /usr/local/grass-7.0.svn/lib/libgrass_gis.so
(gdb)
Cannot find bounds of current function
(gdb)

hope this helps
yann

2008/7/22 Maciej Sieczka <tutey@o2.pl>:

Glynn Clements pisze:

Below that, there isn't actually anything which can cause a segfault.
So, it's very much looking like a broken system.

Gotcha! I'm using GCC 4.3.1 on amd64 Debian testing. Apparently it
doesn't like GRASS default optimisation flags "-g -O2". When I override
them it with e.g. "-pipe" alone, the segfault is gone.

On another machine (Ubuntu Gutsy amd64) where GCC is 4.1.3, "-g -O2" has
no side effects.

Should GRASS enforce any optimisation flags by default?

Maciek

--
Maciej Sieczka
www.sieczka.org

--
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin

Glynn_Clements1 · July 21, 2008, 11:30pm

Maciej Sieczka wrote:

> Below that, there isn't actually anything which can cause a segfault.
> So, it's very much looking like a broken system.

Gotcha! I'm using GCC 4.3.1 on amd64 Debian testing. Apparently it
doesn't like GRASS default optimisation flags "-g -O2". When I override
them it with e.g. "-pipe" alone, the segfault is gone.

On another machine (Ubuntu Gutsy amd64) where GCC is 4.1.3, "-g -O2" has
no side effects.

Ah; a compiler bug. Probably.

Disabling optimisation will often hide actual bugs, but in this case,
that doesn't appear to be possible. The code in question,
lib/gis/geodist.c, doesn't use any pointers; it's just arithmentic and
<math.h> functions.

Should GRASS enforce any optimisation flags by default?

Nope; it should use whichever flags it's told to. The '-g -O2' is
autoconf's default, if CFLAGS isn't set in the environment.

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

Glynn_Clements1 · July 22, 2008, 12:02am

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@gclements.plus.com>

Yann3 · July 22, 2008, 1:00am

wow...
ok then we have to get to GDAL dev list about that...?
Yann

2008/7/22 Glynn Clements <glynn@gclements.plus.com>:

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@gclements.plus.com>

--
Yann Chemin
International Rice Research Institute
Office: http://www.irri.org/gis
Perso: http://www.freewebs.com/ychemin

Maciej_Sieczka2 · July 23, 2008, 4:28pm

Glynn Clements pisze:

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?

The bug is fixed in GDAL in trunk in r14996 and in branches/1.5 in
r14997. See related tickets:

http://trac.osgeo.org/gdal/ticket/2497
http://trac.osgeo.org/gdal/ticket/2494

Maciek

--
Maciej Sieczka
www.sieczka.org