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

[Glynn Clements]

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